In the u2f protocol, my understanding is in the normal case, the web browser seeds the keypair process with the hostname of the remote server. In the case of ssh, the hostname is probably not what I would want to do. But the u2f protocol seems to have a way to handle this. It just needs to be exposed to the user. The content of the private keyfile in ssh is generated somehow. Where is that done? Thanks, Kevin ________________________________________ From: Damien Miller <djm@xxxxxxxxxxx> Sent: Wednesday, January 1, 2020 9:36 PM To: Fox, Kevin M Cc: openssh-unix-dev@xxxxxxxxxxx Subject: Re: u2f seed On Tue, 31 Dec 2019, Fox, Kevin M wrote: > When using openssh with a u2f key, you generate a key via: > ssh-keygen -t ecdsa-sk > > Each time you run it, it gives a different key pair. (Randomly seeming). > > A differently generated key pair is not valid with the first's public key. > > All good so far, but you run into a problem if: > > You generate a keypair (A). > You register your public key for (A) on a bunch of ssh servers. > You take your fido2 key to a second client machine and try and login to your servers. > > It kind of defeats the purpose of being able to have a portable > keyfob. It's possible to use the key on another machine if copy the private key you generated on the original machine over. U2F is almost completely stateless, so there's no way of storing the key on the token itself (for U2F-only tokens anyway) > If there was a way to seed the generation phase manually, then > the same seed can be used on each client machine so that the ssh > pub/private key doesn't have to be transferred along with the u2f > keyfob? That's not possible unfortunately, the U2F protocol doesn't offer any way to set the seed and AFAIK doesn't specify how the tokens generate the keys. There is some good news though, the FIDO2 protocol does support "resident keys" - i.e. keys that can be stored on, and retrieved from a token. I've just started landing support for these in OpenSSH last week. To use them, you'll need a FIDO2 token that support resident keys. You'll also need to set a PIN on the token, as retrieving the keys requires authentication. Once you've done this, you can generate a resident key by running "ssh-keygen -Oresident -t ecdsa-sk" (along with any other usual options). You'll get back a keypair that you can use exactly like any other, but you'll also be able to download it again from the token if you move it to another host. At present the only way I've implemented so far is via "ssh-add -O", which will download all resident keys and add them to a ssh-agent, but I'll add an option to ssh-keygen to explicitly download them to public/private key files shortly. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
