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
[1] https://developer.apple.com/documentation/safari-release-not...
[2] https://developer.apple.com/documentation/ios-ipados-release...
New web sites should do WebAuthn to enable this functionality, here's a guide someone else wrote that I found helpful in talking about the moving parts to actually implement this: https://webauthn.guide/
Firefox's WebAuthn implementation isn't as complete as it would ideally be, but it does have a nice feature of asking the user whether to give out the somewhat privacy-infringing "attestation" from a FIDO2 device when it is requested by a web site. IMNSHO ordinary web sites, especially where a second factor isn't even mandatory, should not be asking for attestation and I always refuse.
https://developer.apple.com/documentation/safari-release-not...
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.
Being able to easily migrate to a new computer sounds like a great feature though.
E.g. other auth, and GPG encryption - such as with `pass`.
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.
Was I wrong to make this assumption? Why would FIDO tokens be significantly cheaper and/or more popular?
If anything it seems like at first it's going to fragment the market even more.
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
I'm incredibly excited about FIDO2, but this is quite underwhelming honestly. I'd like to SSH with a credential on my Yubikey, not by a credential or configuration already stored on my computer that is unlocked by my Yubikey. I'd like to be able to plug in my Yubikey anywhere and go. My Linux desktop, my Macbook, my Windows desktop, my Android phone.
- Yubikey with GPG/PIV for SSH: your Yubikey stores your private key. You can take it anywhere, plug it in, [have to go through all the setup required for your computer to talk GPG/PIV], and log in.
- Yubikey with FIDO2 for SSH: your Yubikey stores a symmetric key to unlock your private key on your computer. [You cannot take it anywhere], plug it in, don't have to set anything up if your client and server have this (eventually), and log in.
FIDO2 is solving a lot of authentication convenience problems, but not this one I think. I get that this pretty nice when integrating with Windows Hello or Apple's TouchID, but I don't think FIDO2 USB key with SSH is that great.
> ssh-keygen -t ecdsa-sk -O resident -f ~/.ssh/id_mykey_sk
I know this is just a reference, but it's still manual configuration. On a host with an SSH client that can speak PIV [this is a challenge], I can just plug in, enter the PIV PIN code, and go.
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.
Once all of those platforms have a more recent OpenSSH, you can ssh-add -K to add keys to your SSH agent.
Sure, a FIDO key is cheaper.
Some get confused or have bad associations when hearing the word 'applet', but that is what they are, as in 'Java applet'.
This one is too https://developers.yubico.com/ykneo-oath/Releases/
Gitlab? No. Github? No. My gateway with a hand built gentoo kernel? Yes.
It seems functional, but you've also got to be aware that `ed25519-sk` and `ecdsa-sk` have sort of spotty support in the devices too. `ed25519-sk` does not work on a Yubikey <5, for example.
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.
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.
Another tradeoff. Some users may be using a cheap or old token (without PIV support) or a token with a private key slot already used for something else. Now, with a software-only upgrade (on both SSH client and server), they can user their existing token for SSH authentication.
That would require an extra press of the token's button for each extra authentication, right?
Would someone please confirm this? If it did require another key press that would be pretty huge.
For that to happen the agent would need to have some way to get the key out of the FIDO authenticator, which is deliberately not intended to be possible. I will now go away and confirm that this behaves as I expected and update this message shortly.
Update: Yes, the OpenSSH agent just has code to go talk to the authenticator each time it needs to sign something. The authenticator may or may not (most seem to not) allow this to happen without verifying user presence (e.g. via a button press or touching a contact) but even if your device does allow this the signed payload says whether the user was present, so a remote SSHD can (if it wanted) demand to see signed evidence of user presence or refuse login, and I think a SSH agent can't fake that without help from the FIDO authenticator itself.
Edit: They fixed it.
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 authenticatorClient-side hardware dependencies:
* USB token with U2F (FIDO) support. FIDO2 is optional. Any old YubiKey or similar will work.
* For the resident key feature only: USB token with FIDO2 support.
* To avoid confusion, only a single USB token should be connected when ssh-keygen is run. (When ssh is run, multiple USB tokens work, the user can touch the wrong one many times, and authentication succeeds after the user touches the right one.)
* ED25519 support in the token is optional. (`ssh-keygen -t ecdsa-sk ...' uses the NIST P-256 curve, which works with all U2F tokens.)
Client-side software dependencies:
* For communicating with the token over USB, OpenBSD or (Linux with udev).
* OpenSSH 8.2p1 or later.
* OpenSSH client (ssh) compiled with `configure --with-security-key-builtin'. Without this, eventually authentication will fail locally with `internal security key support not enabled'. It's possible to work around this by compiling an .so file and specifying it with `ssh -o SecurityKeyProvider=....so', but it's complicated.
Server-side software dependencies:
* OpenSSH 8.2p1 or later.
* Default OpenSSH server (sshd) settings (without PubkeyAcceptedKeyTypes), or PubkeyAcceptedKeyTypes in /etc/ssh/sshd_config containing sk-ecdsa-sha2-nistp256@openssh.com and (optionally, for ed25519-sk keys) sk-ssh-ed25519@openssh.com .
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
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.
All of the docs I have read assume that you are logged in locally on the system, but if you are not (like me) then things fall apart.
I am running a Windows 10 desktop, and then SSH into my local Linux box from Windows. Both systems are sitting next to me and I can press the Yubikey easily.
My local Linux system is running Fedora 32 and I did the following to enable a user connected via SSH to use the Yubikey.
Created a user group for yubikey users, which in reality only has me in it.
Created a /etc/polkit-1/rules.d/99-pcsc-yubikey.rules file which gives smartcard access to the 'yubikey' group. Without this then 'ykman list' would not work.
Created a /etc/udev/rules.d/99-yubikey.rules to give access to the 'yubikey' group. I used /lib/udev/rules.d/69-yubikey.rules as the starting point for my file. I had to add my two Yubikeys USB IDs (lsusb to see them) as they weren't present.
Made sure to log out and back in to have the 'yubikey' group be active for my user. I vaguely remember a command that would do it, but I forgot it.
After all of that I got it to work :)