Hi David, > hmm, what I'm finding doesn't seem to use the FIDO challenge/response to the > server, instead it looks like a public/private key that's unlocked with a touch, > possibly storing the private key on the hardware dongle (but it seems like > there's still a key you need to put on the client system) > > Quoting from the yubikey website: > OpenSSH version 8.2p1 added support for FIDO hardware authenticators. FIDO > devices are supported by the public key types “ecdsa-sk” and “ed25519-sk", along > with corresponding certificate types. > > It then goes on to talk about generating the key with ssh-keygen > > I could easily be missing something about this. Perhaps I'm misunderstanding the nature of your misunderstanding :) I can say that I've been using certs backed by sk keys ever since OpenSSH 8.3 dropped, four years ago. Not only on my personal machines, but I also implemented it in my previous job, both because I like doing it this way, and because I wanted to show them a proof-of-concept. I typically keep at least two yubikeys with separate sk keys on them. This provides redundancy: I can retain access to any infrastructure so long as at least one key is available. Each yubikey can also hold multiple sk keys, eg you might want a different key per job. You do need to export part of the private key onto the client node: `ssh-keygen -K` covers this. Then a typical workflow for me involves signing some other key which will be used for certificate authentication: ``` ssh-keygen -s ~/.ssh/sk/work_ed25519_sk -I tim@<localhost> -n work -V -5m:+8h ~/.ssh/certkeys/work_ed25519 ``` That creates a cert which will be valid for eight hours. The remote servers are configured to accept certs signed by my yubikey together with the principal name of "work". The benefit of this approach is the certificate is time-limited and backed by 2FA, but you can go ahead and use the certificate without demonstrating user presence (i.e. touching yubikey) at every point in a chain of proxyjumps. It provides what I consider to be a nice balance between security and convenience. Cheers, Tim _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
