Automatic FIDO2 key negotiation (request for comments)

Jordan J jordandev678 at
Tue Jul 21 03:46:52 AEST 2020

At present whenever non-resident keys are used the key_handle required
to use the token must be given by selecting the ssh 'private key' file
generated by ssh-keygen during negotiation.

In the more common webauthn context this key_handle would be stored on
the server and then transmitted to the client during authentication.
The client then checks connected tokens for one that reports it
understands that key_handle and can sign on its behalf. Compared to
SSH this approach means there are no external files required to use
the hardware key (use is just plug and play).

The initial patches for U2F added it as a new authentication method
and were dropped in favour of the current implementation where it is
mostly just another key type with an external signature provider. This
is a less invasive change but means that the information required to
do a more 'typical' negotiation supporting this plug-and-play use
isn't available.

However that degree of plug-and-play is desirable in some
circumstances. Particularly those where the user may be logging in
from different transient machines. The current method requires the
user to carry around the security key as well as the 'private key' on
a USB stick so that both can be accessed. Not fatal by any means, but
not ideal compared to a more typical webauthn flow.

(onto the questions)

Firstly, would the following or some combination thereof be possible
or is there an obvious impediment. Secondly, if it proved possible are
the maintainers open to a patch providing it?

1. Update the SSH ecdsa-sk public key type to contain the key_handle
and other relevant details (it doesn't contain sensitive information
or accessible key material so this is safe to do)
2. Add a method to send a list of understood *-sk" publickeys from
authorized_keys to the client

An appropriate method to implement #2 without reverting to the more
invasive alternate-auth-method would seem to be via SSH extensions
(RFC8308). If both the client and the server signal their support for
the extension a list of known *-sk keys could be sent after a user is
selected. This would then let the client select a key without needing
the private key file. This should also prevent any incompatibilities
between clients with and without support. They can use the external
file the same as they do now.


More information about the openssh-unix-dev mailing list