[Bug 3366] SSH should skip sk-* keys that don't match the connected security key

[bugzilla-daemon at mindrot.org]

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

--- Comment #6 from Erik Jensen <businesscorrespondence+openssh at rkjnsn.net> ---
If I'm understanding correctly, shouldn't that be "it will only improve
matters for *non-biometric* keys"? If I'm reading Pedro's explanation
right, it sounds like the problem for biometric/uv tokens is that
there's no way to test whether a credential belongs to the token
without requiring a gesture, as attempting to sign an unknown
credential and attempting to sign a known credential without a
user-verification gesture both fail with the same error, so the only
option is to assume the credential might belong to the token and try it
with a user-verification gesture.

The change in b5601202, then, keeps the logic introduced in b969072c
intact for biometric/uv keys: if there is a single token connected, and
that token supports on-token user verification, that key will be
selected for signing with a uv gesture unconditionally, since there's
no way to test whether the credential belongs to the token ahead of
time. However, with b5601202, ssh will no longer try to use a single
non-biometric, non-uv token unconditionally, as such a token *can* be
tested before requiring a user gesture. Instead, sk_select_by_cred will
now invoke sk_try for the key, the same as it would if multiple keys
were attached, and only return it if that succeeds.

(Given this understanding, I think the commit message for b5601202 is
incorrect, though the change itself is correct, since it is actually
tokens that do *not* support on-token user-verification that are now
asked if the credential belongs to them.)

In any event, with b5601202 applied to my ssh-agent, I now see my
desired behavior with my YubiKey 5s: when only one token is attached,
attempting to use the key that doesn't match that token immediately
fails, so I only have to touch my token once, even when the matching
key is tried second. Thanks!

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.