Not sure if applicable to your use-case, but I'm using a HyperFIDO Mini[1]. Much cheaper than the Yubikey, and the form factor is also nice for just keeping it in a (reachable by hand) USB port. Though I carry mine on the keychain (and have an older, bigger one at home as a backup).
/me looks at his collection of electronic parts: Absolutely :) However, there is only so much time one can spent on this. Reminds me I should continue working on some FOSS after $dayjob is done for today...
Oh, it's just U2F? You want FIDO2 with resident key support to get the really nice OpenSSH workflow (plug the key in to a new computer, run ssh-add -k, now you can SSH to all your computers).
Last time I tried there were a few, more complex commands than this. Could I use a udev rule to add my SSH keys as the device is plugged so I don't have to run anything?
Yes you can, SSH 8.3ish uses FIDO2 and doesn't do anything Yubikey-specific. That means you don't have to bother with all the agent stuff, and it works with any dirt-cheap FIDO2 key.
EDIT: I'm going to post a writeup tomorrow detailing how to do this, because it's wonderful and super secure.
Yes, any vaguely modern YubiKey implemented FIDO2 which is what you need.
However you need fairly modern OpenSSH (this year) for both clients and servers. Both need to be upgraded because the authentication protocol itself is different, so an older server has no idea how to authenticate with FIDO2.
To get the behaviour the parent describes you must make sure to follow the instructions for resident keys, and these instructions won't work on cheaper FIDO (not FIDO2) devices that designed be used as second factors. Without resident keys the authenticator only works when at the computer you used to enrol it, which is fine for a personal workstation/ laptop but not great if you need to roam.
Thanks, I have a few 5C's so they should be new enough, I'll need to check my laptop/desktop to make sure SSH is new enough (I run Ubuntu 20.04/Manjaro respectively).
My servers most likely aren't, but I run most of my workloads in Docker or Kubernetes so it's just a matter of time to get them all updated.
FIDO2 enables resident keys. With resident keys the web site can have a flow where you just go "It's me" (maybe you enter a PIN, or touch a fingerprint sensor, Apple just announced they're doing this with FaceID) and you're signed in. Without a resident key, there's a back and forth where you give a username, then maybe a password, and then your authenticator comes in to provide a second factor.
This is because the FIDO2 device actually has (finite) slots to remember e.g. credentials for funky-jokes.example so when you're at funky-jokes.example a WebAuthn API call can ask for those credentials and sign you in. No username, no password, you've presented all the credentials needed in one step. Whereas when keys are not resident the authenticator is relying on the web site to know (from your username) its ID, without being told the ID it can't do the authentication dance, so you will need to enter a username/ email address.
Resident keys are clearly a great idea in a phone (iPhone, Pixel, whatever) because it's not like gigabytes of flash storage will be exhausted storing credentials for the dozens or even thousands of sites you have credentials for.
It's less obviously a great idea for a Yubikey or cheap USB Security Key that maybe only has space for a dozen credentials. Maybe it makes sense to use it for that one web site you sign into every day, or to replace the main SSH key you use but if a Yubikey has 25 slots it doesn't make much sense for one to be "bush-jokes.example" which you last visited ten years ago...
That sounds worse to me. I don't like the idea of having my identity tied to a device. What if I lose it? My favorite setup right now is to keep my username / password in a password manager that I sync to multiple places to ensure it doesn't get lost. Then I use a YubiKey with FIDO / U2F on sites I consider important. I have a main and a spare YubiKey and both get added to my profile (except AWS who only support one key).
All the FIDO2 capable devices I'm aware of are intended to be used with some external factor. For a Yubico Security Key 2 that's a PIN (unlike your passwords the PIN isn't sent anywhere, it's verified by the device) and some other devices use a fingerprint. Platform authenticators are going to do all sorts of stuff, like Apple's FaceID.
So if you lose it the credentials are now essentially worthless (anybody who found it or stole it presumably doesn't have your PIN / fingerprints / face) and you should revoke them from sites where they were trusted.
Nothing prevents you from enrolling multiple FIDO2 resident key devices for a site, the site would store all the relevant credentials and you could use any of them to log in. I expect Apple's implementation notes for that demo last week tell implementers to allow multiple enrolment because some of Apple's best customers own an iPhone and an iPad and a MacBook Pro and expect to use all three.
But sure, you can use the second-factor-only FIDO behaviour on a FIDO2 key just fine, it's just that FIDO2 resident keys can offer a nicer user journey while still being secure.
The thing to be wary of here is knowing which platform should be used, on a given site. These devices are to establish strict lines of trust, but not all those who use them are technically proficient, so a MitM that downgrades the authenticator from "platform" to "cross-platform" (or roaming) can alter the registration process such that what should have had a biometric tie now just has a PIN (or no PIN depending). This attack depends on how the vendor is managing AAGUIDs and Attestment Certificates, but a lot simply don't.
This seems like a pretty complicated attack with relatively low value, but maybe I don't understand something important. So let me run it back by my understanding.
You're proposing a TLS MitM (maybe plausible in a corporate environment that has this configured anyway) which downgrades the authenticator enrolment to have less protections, and then passing the resulting credentials to the real backend which will assume it has two factors without checking?
And later you steal the device so you can now use it without an additional factor because it wasn't enrolled using multi-factor anyway.
This would work as an element of the over-complicated schemes in an Oceans movie, but it doesn't feel very plausible in the real world. The skill sets to "Steal someone's iPhone" and "Obtain fraudulent Web PKI certs" don't overlap very much and this attack doesn't scale so it would need to be targeted.
I didn't explain it really well. I wasn't too worried about it being stolen. I was worried about having a single device, so losing it means losing all the identity info. I guess it's no different than now where I enroll 2 keys everywhere.
I didn't try any command line utilities and only use it for the web with Firefox (e.g. GitHub). Can confirm: Works well on both Linux (needs some udev rule, but I think that's true for all these sticks?) and Windows.
To further answer GP: Lacks Bluetooth/NFC, so it's not usable with a smartphone (okay, maybe with a large USB-OTG adapter). No idea on the supported protocols, I think Yubikeys offer a lot more options there, but it's good enough for web authentication.
Manufacturer support was pretty good: My first token was DOA, and I got a replacement token plus a free Mini. The replacement is now my backup unit and, as mentioned, carry the Mini on my keychain.
Oh, that's really weird. I got it from .de delivered to DE. Maybe send the manufacturer a mail and ask them to fix it? Mine came DOA and I remember them to be pretty friendly.
[1] https://hypersecu.com/tmp/products/hyperfido