For many years now, I’ve been using an old YubiKey along with the free tier of Duo Security to add a second factor to my SSH logins. This is klunky, and has a number of drawbacks (dependency on a cloud service and Internet among them).
I decided it was time to upgrade, so I recently bought a couple of YubiKey 5 series security keys. These support FIDO2/U2F, which make it so much easier to integrate with ssh.
But in researching how to do this, I found a lot of pages online with poor instructions. Either they didn’t explain what was going on very well, or suggested what I came to learn were insecure practices, or — most often — both.
It turns out this whole process is quite easy. But I wanted to understand how it worked.
So, I figured it out, set it up myself, and then put up a new, comprehensive page on my website: https://www.complete.org/easily-using-ssh-with-fido2-u2f-hardware-security-keys/. I hope it helps!
Thank you for this excellent post. I have a question – since residential keys can be recreated with the -K switch, how are non-resident keys recreated (if at all possible)? Or do I have to move the private key (that holds the key handle) to all the hosts I might need to make the connection from? Or do I always have to create a new, unique keypair from the said hardware key on new hosts? I find it a bit easier and less cumbersome with the residential keys since the keypair always can be easily recreated.
@hakayova With the SK key, think of it like this: the real private key can only be constituted by combining the key handle stored in ~/.ssh with a private key stored within the SK. It is impossible to access the real private key; all operations involving it must take place within the SK. So compromise of your private key file alone can’t lead to access anywhere. (This assumes non-resident keys)
The SK is automatically required when you give one of the sk keytypes to ssh-keygen -t.
Mersin Satılık Villa
@mkj Wow, there’s a bug in Hugo, I guess. Hopefully I got it fixed now. Thanks for letting me know!