A little series of hurdles later and I have the key unlocking KDE4. Some of the issues you are likely to see are that /etc/yubikey needs to be +rw by whatever is trying to use it. So making a yubifoo group and setting /sbin/yk_chkpwd to be setuid that group can be a plus. The biggest problem I had was trying to get the YubiPAM module to unlock KDE. It turns out that it was getting the user name and sending that to a child yk_chkpwd to verify instead of sending the current auth token.
To fix it, you might like to mangle pam_sm_authenticate() to use the following to get the authtok and send it through as the one time password for verification...
const char *prompt = 0;
const char *authtok;
int rc = pam_get_authtok( pamh, PAM_AUTHTOK, &authtok, prompt );
if( rc == PAM_SUCCESS )
{
otp = authtok;
}
REMOVE these two lines which don't seem to work
otp = get_response(pamh, "Yubikey OTP: ", verbose_otp);
retval = pam_set_item(pamh, PAM_AUTHTOK, otp);
With this in place and the normal line in /etc/pam.d/kscreensaver:
auth sufficient pam_yubikey.so
the key should unlock you, or a regular password too. If you want two phase then it is easy to hack that into pam_sm_authenticate() looking for a pin prefix inside the authtok. Breaks the rules of module stacking in PAM, but works as they say.
To setup an offline aes key, make one somehow and use
ykpersonalize -o fixed=$modhexwhatever -a $aes_key_here \
-o -static-ticket -o -strong-pw1 -o -strong-pw2 \
-o -man-update
ykpasswd -d $my_user_name
ykpasswd -a $my_user_name -k $aes_key_here \
-f $modhexwhatever \
-o OTP
ykvalidate -u $my_user_name OTP
where OTP indicates a tap of the yubikey.
You can also get a layer down from ykvalidate using
echo -n OTP | /sbin/yk_chkpwd $my_user_name
There are other groovy scripts around to lock the screen when the yubikey is removed from the machine which might be a nice next step... now that it actually works to *un*lock.