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!
I recently wrote about How to Use SSH with FIDO2/U2F Security Keys, which I now use on almost all of my machines. The last one…
Wait, I don’t get this.
First, I guess the major reason why other articles — which I have not read — recommend `–resident` is that the YubiKey 5 Series Technical Manual doesn’t even seem to mention nonresident keys. Right? So from the start I’m afraid I would be doing something out of spec.
Second, in the part of your article about nonresident keys, where does the yubikey come into play? I can’t see it. Surely you have to do *something* to it to make it all work?
Thanks for your explanation,
—
Ian
Hi Ian,
Nonresident keys are a standard part of the FIDO2 standard so it is absolutely normal. You will get an error if you do something out of the spec.
With nonresident keys, think about it like this: the host computer holds encrypted key material. But the computer doesn’t hold the keys needed to decrypt it. Only the Yubikey has those, but also note that the Yubikey won’t ever reveal the decrypted key material. In order to do something with the private key, the host sends both the private key and the information about the operation it needs to perform over to the Yubikey. Once the Yubikey receives a touch, it will decrypt the key material internally, perform the requested crypto operation with it, and send the result back to the host.
The details are a bit more complex but hopefully this helps!