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. Comments? _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
