[Bug 3572] ssh-agent refused operation when using FIDO2 with -O verify-required

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Sat Jul 15 08:19:45 AEST 2023


https://bugzilla.mindrot.org/show_bug.cgi?id=3572

xspielinbox+mindrot at protonmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xspielinbox+mindrot at protonm
                   |                            |ail.com

--- Comment #1 from xspielinbox+mindrot at protonmail.com ---
I came across the same issue using Fedora Linux 38 with OpenSSH_9.0p1,
OpenSSL 3.0.9 and a YubiKey 5 NFC with firmware version 5.2.7 and
libfido2 1.12.0-3.fc38

When creating the ssh-key of type ed25519-sk (regardless of the options
given) it asks for the FIDO pin of the security key.
In the default config (which uses an ssh-agent) it does never
thereafter again ask for the FIDO pin of the security key, no matter
how it has been created (resident or not; with verify-required or not).

When explicitly running ssh with an invalid ssh-agent socket, it does
correctly ask for the pin, if the key has been created with
verify-required, but not if it hasn't:
$ SSH_AUTH_SOCK=/tmp/ssh.sock ssh user at host -i id_ed25519_sk_verify
Enter PIN for ED25519-SK key id_ed25519_sk_verify:
Confirm user presence for key ED25519-SK SHA256:[...]

$ SSH_AUTH_SOCK=/tmp/ssh.sock ssh user at host -i id_ed25519_sk
Confirm user presence for key ED25519-SK SHA256:[...]

When using a key without verify-required with the default ssh-agent
config and specifying verify-required in the authorized_keys of the
target system, it does correctly deny the key with 'debug3: receive
packet: type 51', though this is an pretty ambiguous failure message...

All in all, I can reproduce the reproduce the reported issue. To an
user at first it seems like the verify-required option is useless or
broken, as is does not change anything.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


More information about the openssh-bugs mailing list