How to use FIDO2 USB keys with SSH

Here's a browser compatibility matrix (I know, OP is about SSH).

FIDO2/U2F Just Works in:

    Chrome on Windows
    Firefox on Windows
    Chrome on Mac
    Firefox on Mac
    Chrome in Ubuntu 20
    Firefox in Ubuntu 20

    Safari

That's very useful, thank you! I've been looking for something that goes into a bit more detail, so your talk is timely.

You misunderstand how FIDO2 works. Read the article, it details how to do exactly what you say it can't. You can resume your excitement now!

"Yubikey with GPG/PIV for SSH"

There's no need to mess around with the GPG side of the Yubikey to get SSH working. Just the "plain" side of the Yubikey will work (which is great on a Mac because all you need is the basic dylibs - downloadable from Yubi and easily mv/cp installable in the relevant lib dir - rather than needing to mess around installing gpg). Added bonus is you enforce touch for key usage.

You can, that's exactly what resident keys in this article is referring to.

Once all of those platforms have a more recent OpenSSH, you can ssh-add -K to add keys to your SSH agent.

FYI Another client-side software dependency: libfido2 >=1.3.0. It doesn't work with libfido2 1.2.x or earlier.

Also, if it doesn't work on your client system only because OpenSSH 8.2 was compiled without `configure --with-security-key-builtin', here is how to make it work: https://github.com/pts/external-sk-libfido2

That's a good point, I haven't tried it but I think you're right, which is another great benefit of using hardware tokens.

I would assume the agent caches the key for signing.

Would someone please confirm this? If it did require another key press that would be pretty huge.

It depends on how you configured your Yubikey. I believe you can configure it both ways.

I think those are pretty much the only ones, the Yubikey in GPG smartcard mode was always too fiddly for me and interfered with my agent in other ways, but this is trivial to set up and use.

Also, a big draw of the USB SSH key for me is that I can plug it in to other computers and connect to my servers, which smartcard mode didn't do, so that was a big drawback for me.

You can use an OpenPGP card more generally than just for SSH auth.

E.g. other auth, and GPG encryption - such as with `pass`.

Going FIDO-SSH can perhaps be cheaper than PIV, especially if, as we very much want, FIDO is popular which will tend to drive down prices.

Cheaper/ simpler FIDO2 products (from Yubico) exist if this feature is the only thing you want from a Yubikey. I don't know if that's a future Yubico are enthusiastic about, but I don't see much reason to hate it as an end user.

Even cheaper and even simpler FIDO products (from many vendors) exist if you only ever actually want this from one or two systems (e.g. a laptop and then one desktop workstation) so you don't need resident keys because the "non-resident" part lives on your workstation.

If it's been stable for you, that definitely works well but I found OpenSC to be unstable and required hotplugging the device and/or killing gpg-agent on a regular basis.

Mac users do have built-in support which works the same way with certificates and is more stable in my experience:

https://piv.idmanagement.gov/engineering/ssh/#ssh-from-macos

Same here, and I just absolutely love how well it works. Now if Android SSH apps add support for it, my SSH life will be complete.

Should've asked around, there were devices, standards and software for this kind of thing for a while e.g. https://github.com/philipWendland/IsoApplet

Waited 10 years? Why didn't you just use a yubikey in PIV mode, or the yubikey with gpg, or a smartcard, or… I've been using a yubikey PIV for, hmm… at least 5 years.

Sure, a FIDO key is cheaper.

If you wish. You can decide if you want a passphrase on the generated key or not, just as you can with a classic SSH key. It's probably best to use a passphrase and have ssh-agent remember it for you until you shut down the computer. That way you enter your passphrase the first time using SSH with that key after logging in, and ask you to tap the physical U2F key, and only ask for the interaction with the physical key afterwards.

When I SSH to a host configured like this, the Yubikey U2F key I am using blinks to ask me to touch it. It's really quite neat.

they have the addition of -O resident

from ssh-keygen:

       resident
              Indicate that the key should be stored on the FIDO authenticator itself.  Resident keys may be supported  on
              FIDO2 tokens and typically require that a PIN be set on the token prior to generation.  Resident keys may be
              loaded off the token using ssh-add(1).

        -K     Load resident keys from a FIDO authenticator

Sorry, copy/paste fail. Fixed now, thanks!

Not really but it's just Lektor and Netlify, hosted on Gitlab. I also have Gitlab CI deploying the site on Neocities (https://neo.stavros.io/) as a backup/just to see if I could.

> Be aware literally nothing supports this unless it's your own kernel.

Ubuntu 20.04 and later supports this, and, since that's LTS, it means that quite a few servers and machines will be supporting it already.

Github/Gitlab aren't supporting it yet, but given how great it is for security, I think they have a big incentive to speed up support.

> ed25519-ek does not work on a Yubikey <5, for example.

That's no problem, since you can just generate an ECDSA key instead, but yes, not all keys have hardware support for all algorithms.

Not exactly true. Ubuntu 20.04 supports this out of the box and lots of VMs therefore also do.

Not only that, but there's billions of devices out there that don't support it.

I can SSH to my AP, my home router, all routers at basically any ISP. None of those support this. Most of them probably never will, until they're thrown away and new ones bought in 5-10 years.

Bottom line: This can't be your only key. So why bother? Why not use PIV mode/smartcard/other, which does work with every single one of these billions of devices, because they have no server-side requirements like these.