[Bug 3366] New: 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

            Bug ID: 3366
           Summary: SSH should skip sk-* keys that don't match the
                    connected security key
           Product: Portable OpenSSH
           Version: 8.8p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: businesscorrespondence+openssh at rkjnsn.net

I have two U2F tokens and would like to be able to use both of them for
SSH access, and hence have created an ecdsa-sk key for each of them,
and authorized both on the server.

If I don't have either token plugged in, ssh will print out a "signing
failed" message for each of the signing keys and skip them, which makes
sense. If I have both tokens plugged in, ssh will look at the first
signing key, correctly determine to which token it belongs, and then
request a touch from that token.

The issue is that if I only have the second token plugged in (which is
often), ssh will unconditionally wait for a touch from it when trying
the first signing key even though the two don't match. Only after
receiving the touch will ssh realize that the key doesn't belong to the
attached token and move on to the correct signing key, which requires a
second touch. As a result, I'll have to touch my token twice to connect
(e.g., for every remote git operation), which is annoying.

It would be nice if ssh checked if first signing key actually belonged
to the connected token *before* waiting for a touch so it could
immediately skip it and I'd only have to touch my token once to
connect.

Looking at the code, it appears fixing this issue would be as simple as
reverting this change:
https://anongit.mindrot.org/openssh.git/commit/?id=b969072cc3d62d05cb41bc6d6f3c22c764ed932f

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