You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a U2F zero, delivered in Feb 2018 to the UK. It may be a bad one, but in 2018 I successfully registered it with Google 2FA on Firefox and used the key several times to authenticate over the next year or so.
I haven't used the key since then, but yesterday I tried to set up pam-u2f for login.
Registering works fine: pamu2fcfg -u zoom >> /etc/u2fkeys.
The key's led flashed, I pressed the button and the output seems OK.
But login authentication failed.
I tried to use the key to authenticate to Google yesterday; that now doesn't now work. Earlier today, I successfully registered the key for 2FA with github and on my personal nextcloud instance. Registration works fine, but Firefox won't authenticate. When I try, Firefox pops up a window which says <server> wants to authenticate you using a registered security key. You can connect and authorise one now, or cancel. But I don't get an option to use the key, only the cancel button.
So it seems that both Firefox and pam are doing the same thing, which suggests that the cause lies in either user space libraries or the kernel.
I can reproduce the login problem with pamtester: here is a redacted debug log. I'm removing all the sensitive data, but what I see looks convincing.
The hid-u2fzero module loads OK. I see no problem with e.g. selinux denying access to anything: this is what syslog sees while pamtester runs. It would seem that there is an I/O problem, but only after a couple of exchanges are completed. I understand that the problem with the bad batch was with command 0x07; I see only 0x06 and 0x03.
Ideas? Is there a sanity check for U2F Zero which can pin down where the problem is? I assume that pam-u2f hasn't suddenly stopped working and that Yubi or Nitro keys are probably OK, but I don't have either to hand for comparison. None of the bad key workarounds for pam-u2f such as nodetect, cue or manual affect this failure.
I have a U2F zero, delivered in Feb 2018 to the UK. It may be a bad one, but in 2018 I successfully registered it with Google 2FA on Firefox and used the key several times to authenticate over the next year or so.
I haven't used the key since then, but yesterday I tried to set up pam-u2f for login.
Registering works fine:
pamu2fcfg -u zoom >> /etc/u2fkeys
.The key's led flashed, I pressed the button and the output seems OK.
But login authentication failed.
I tried to use the key to authenticate to Google yesterday; that now doesn't now work. Earlier today, I successfully registered the key for 2FA with github and on my personal nextcloud instance. Registration works fine, but Firefox won't authenticate. When I try, Firefox pops up a window which says
<server> wants to authenticate you using a registered security key. You can connect and authorise one now, or cancel.
But I don't get an option to use the key, only the cancel button.So it seems that both Firefox and pam are doing the same thing, which suggests that the cause lies in either user space libraries or the kernel.
I can reproduce the login problem with pamtester: here is a redacted debug log. I'm removing all the sensitive data, but what I see looks convincing.
The hid-u2fzero module loads OK. I see no problem with e.g. selinux denying access to anything: this is what syslog sees while pamtester runs. It would seem that there is an I/O problem, but only after a couple of exchanges are completed. I understand that the problem with the bad batch was with command 0x07; I see only 0x06 and 0x03.
Ideas? Is there a sanity check for U2F Zero which can pin down where the problem is? I assume that pam-u2f hasn't suddenly stopped working and that Yubi or Nitro keys are probably OK, but I don't have either to hand for comparison. None of the bad key workarounds for pam-u2f such as nodetect, cue or manual affect this failure.
The text was updated successfully, but these errors were encountered: