On Mon, 20 Jul 2020, Jordan J wrote: > 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. Right, this was an deliberate decision. Another motivating factor was being able to use existing non-OpenSSH SSH tooling and workflows with only small changes. > 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 I'm not keen on making the public keys contain the key handle. IMO being able to offer some protection of the key handle on disk by setting a password on the key is valuable and we'd lose that if everything were public by default. > 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. If you do this, then you don't need step #1 at all: the server could send the key handles registered for a user at the start of userauth and the client could proceed to match them against their available hardware authenticators and return a signature using one. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
