Open kanru opened 2 years ago
Yeah, this is a bug (not responding to both pre and official code), will be fixed in next release.
@nickray do you have any idea when that could be? solo2 is so so close from being usable in my case but lack of resident keys is real blocker. I'm unsure if it's better to continue waiting or order the newest yubikeys.
@arathunku I ordered (only) one yubikey 5. Works out of the box and there are some nice KeePass plugins. Also has a usable OTP App for Windows in Microsoft Store, although mediocre. Given the current speed of development, i think we will have to wait one year or more to get usable software :-(
To add to the above i am also unable to get resident key ssh working on the solo 2.
@pbl987 yubico just released an updated TOTP app (in beta) for desktop which works fairly well. https://www.yubico.com/blog/introducing-yubico-authenticator-6-for-desktop/
Discussed further in https://github.com/solokeys/solo2/discussions/108, I believe this should work now. @kanru do you have the current firmware version, and does your device have both a PIN and an openssh "sk" credential?
@nickray I updated to latest firmware. Now I'm getting FIDO_ERR_INVALID_CREDENTIAL
$ solo2 ls
Solo 2 XXXXXXXXXXXXX (CTAP+PCSC, firmware 2:20220822.0, unlocked)
$ fido2-token -I /dev/hidraw1
proto: 0x02
major: 0x02
minor: 0x03
build: 0xc4
caps: 0x05 (wink, cbor, msg)
version strings: U2F_V2, FIDO_2_0, FIDO_2_1_PRE
extension strings: credProtect, hmac-secret
transport strings: nfc, usb
aaguid: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
options: rk, up, noplat, credMgmt, clientPin, credentialMgmtPreview
maxmsgsiz: 3072
maxcredcntlst: 10
maxcredlen: 255
fwversion: 0x0
pin protocols: 1
pin retries: 8
uv retries: undefined
$ fido2-token -I -c /dev/hidraw1
Enter PIN for /dev/hidraw1:
existing rk(s): 2
remaining rk(s): 98
$ rpm -q openssh
openssh-8.8p1-1.fc36.1.x86_64
$ ssh-add -K -v
Enter PIN for authenticator:
debug1: start_helper: starting /usr/libexec/openssh/ssh-sk-helper
debug1: sshsk_load_resident: provider "internal", have-pin
debug1: sk_probe: 1 device(s) detected
debug1: sk_probe: selecting sk by touch
debug1: ssh_sk_load_resident_keys: trying /dev/hidraw1
debug1: read_rks: existing 2, remaining 98
debug1: read_rks: get RPs for /dev/hidraw1 failed: FIDO_ERR_INVALID_CREDENTIAL
debug1: ssh_sk_load_resident_keys: read_rks failed for /dev/hidraw1
Provider "internal" returned failure -1
debug1: ssh-sk-helper: sshsk_load_resident failed: invalid format
debug1: main: reply len 8
debug1: client_converse: helper returned error -4
Unable to load resident keys: invalid format
$ fido2-token -L -r /dev/hidraw1
Enter PIN for /dev/hidraw1:
fido2-token: fido_credman_get_dev_rp: FIDO_ERR_INVALID_CREDENTIAL
$ fido2-token -D -b -n ssh: /dev/hidraw1
Enter PIN for /dev/hidraw1:
fido2-token: lookup_key: fido_credman_get_dev_rk: FIDO_ERR_INVALID_CREDENTIAL
I can't use fido2-token to reset the key. But I managed to use chrome to reset the key, then I reset the pin and now I can create and download resident keys. 🎉
Per my comment in https://github.com/solokeys/solo2/discussions/108#discussioncomment-3627818, I discovered that on Ubuntu 20.04, fido2-tools
1.3.1 doesn't work ($ fido2-token -I -c /dev/hidraw0
gives fido2-token: fido_credman_get_dev_metadata: FIDO_ERR_MISSING_PARAMETER
), but if I build libfido2
from source and install, thereby ending up with version 1.12.0 of that library, then it works fine. Hope this helps someone else.
Unable to download resident keys. It looks like ssh/libfido2 is still using the 0x41 code defined in FIDO_2_1_PRE, not the FIDO_2_1 one 0x0A implemented in ctap_types.
The
debug1: check_sk_options: option uv is unknown
line in ssh is printed after checking thefido_credman_get_dev_metadata()
returnsFIDO_ERR_INVALID_COMMAND
Originally posted by @kanru in https://github.com/solokeys/fido-authenticator/issues/3#issuecomment-1055505888