I have been trying to use Yubikey for SSH over the years, and everything has been a huge hassle that just didn't work well enough.
Everything, that is, until SSH 8.2 came out. Using a Yubikey (or any other U2F-compatible key, which is a lot of them) is a breeze: Run `ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk` to generate a key from your Yubikey and you're done. You can even use Resident Keys mode (if your key supports it) to avoid having to carry the private-key-half around with you, you can load it straight from the Yubikey with `ssh-add -k`.
This is the only way that lets you walk up to a machine, plug your key in and SSH to your server securely with just two commands. The downside is that both sides have to be running SSH 8.2+.
> The downside is that both sides have to be running SSH 8.2+.
This is the problem. I was really excited for FIDO SSH keys, but LTS server distributions don't support it so it's going to take years for broad adoption.
The new OpenSSH keys are very convenient if used correctly, but have a crucial disadvantage compared to the PIV-based approach of yubikey-agent: They currently can't be protected effectively with a PIN, so you should take good care of your security key or require multiple authentication methods on your server.
You can set a FIDO2 PIN on your security key and it will prevent ssh-keygen/ssh-add from regenerating the key files without it. But the relevant information (the key handle) can also be retrieved from the key in other ways that don't require the PIN. This is likely going to be fixed in a future version of OpenSSH, but may require a more recent kind of FIDO2 key. Until then, you should consider resident OpenSSH keys to provide only single-factor authentication ("possession"), even if a PIN is set on the security key.
The tokens are engineered to protect the private key material stored inside them very well, so you can be quite certain that nobody will ever be able to log in without physical access to the key (to touch/press the button).
However, the SSH protocol differs quite substantially from the FIDO2/WebAuthn spec in how it uses the PIN set on the token. Depending on how the SSH server is configured and which defaults your security token's manufacturer chose, it may be the case that the PIN is not needed to log in (assuming physical access to the token).
I hope that all of this will be clarified in the OpenSSH documentation at some point as it is quite vague about security guarantees at the moment. It's probably best to use the non-resident version of the new key type together with a passphrase on the key file for now, or rely on the PIV applet instead.
Oh huh, that's unfortunate. I was under the impression that the Yubikey would not sign anything without a PIN, period, and that it wipes its contents after three (ten?) wrong attempts. This greatly reduces the security of the token, and it's a shame since we were so close to perfect...
It does not. From an `ssh -vvv git@github.com -i <path/to/sk key>` session:
debug1: Next authentication method: publickey
debug1: Offering public key: <path redacted> ED25519-SK SHA256:<pubkey redacted> explicit authenticator
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
Only RSA keys are supported by default on AWS. Surely, if you can run some arbitrary cloud-init code to initialize the instance you can install whatever is supported by the sshd in the image.
I had problems pushing for solutions that used non-RSA public keys in my $dayjob because of this
Ok so this is neat; while the newest openssh client/server directly supports u2f keys, this is a badass shim that creates NIST-p256 compatible keys that are backed by a YubiKey.... man I wish this was a thing about 2-3 years ago!
Personally I've been using gpg-agent for a 2 years now without issues. It's also nice because your ssh key could be signed and be discoverable on public keyservers (like keybase), but I don't see any cloud providers having that integration yet.
I can confirm the author's experience with Apple's SSH-agent implementation. It does not allow you to load Yubikey agent libraries from Homebrew's default /usr/local, which makes it an inconvenience to set up.
It surely depends on the OS, and on the PKCS#11 implementation. I tested ykcs11 and OpenSC on macOS and they were like I described. I had started this project as a simple setup tool for PKCS#11 configurations and had to build the agent to get the UX I wanted.
Also, not having to re-enter the PIN after unplug means it's being cached in memory rather than on device, which I'm not a fan of. In yubikey-agent that's handled by using a graphical pinentry during operation to avoid the manual unlock step.
Yeah I had the same experience using OpenPGP applet on the Yubikey both on Linux and Windows. It just works. Maybe it was a problem once but got improved with time?
Doesn’t having the same key on multiple devices kinda ruin some of the point of the yubikey? What if you wanted to revoke one after you lost it? Also, how do you store your gpg key? I have a couple yubikeys, but I have different keys on each of them, and I find that works just fine.
It's not a big problem because tokens lock themselves after 3 tries so even if someone got your token they'd have to guess it. Having separate subkeys for each token is nice but works best only with the signature subkey. For encryption it doesn't work as GnuPG encrypts only to one subkey. The same with authentication subkey: it doesn't matter if you revoke it because SSH doesn't understand OpenPGP revocations.
It was some time when I read the explanation on how do they want to approach this but I guess the card identifier will no longer be needed (or all card ids will be stored).
Is it considered good practice to create the key on the yubi and not have a backup? Or alternatively a master key to sign the key on the yubi so you can create a new subkey if you lose the yubi?
Ideally each key will be generated on the device and be unexportable. That's a major part of the value of a Yubikey/smartcard/HSM, because it provides Non-Repudiation, and it enables you to be reasonably certain that it is impossible for the key to exist outside of the physical device.
You can use multiple devices to generate multiple keys to give you persistent access in case a device fails or is lost. Software generally accommodates multiple (public) keys per client for this reason.
With an SSH CA, the server ultimately trusts the CA key, and client keys are used for authentication via the client certificates. I think you can use Yubikeys and relatively inexpensive HSMs (eg. Nitrokeys) for this.
Thank you very much for the link, I missed that discussion. I had no idea the security of OnlyKey was so terrible, in light of this I will stop recommending it.
Thank you for the alternative. Sadly it doesn't support SSH or GPG keys, does it? That was one of the selling points of the OnlyKey for me (and it being open source of course).
I'm not sure if they will support those yet. I could never get SSH working well, whereas SSH with U2F works perfectly (and they do support that). I'm guessing they will add GPG key integration, as once the key can perform crypto operations, it's just a matter of host software.
Make sure you read down on this thread https://news.ycombinator.com/item?id=21884184 there is a lot of misinformation in the top posts that are completely debunked if you read down. Like someone said OnlyKey is an Arduino which its not and that it doesn't have hardware security which it does. You can find full list of hardware security features here - https://docs.crp.to/security.html
Everything, that is, until SSH 8.2 came out. Using a Yubikey (or any other U2F-compatible key, which is a lot of them) is a breeze: Run `ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk` to generate a key from your Yubikey and you're done. You can even use Resident Keys mode (if your key supports it) to avoid having to carry the private-key-half around with you, you can load it straight from the Yubikey with `ssh-add -k`.
This is the only way that lets you walk up to a machine, plug your key in and SSH to your server securely with just two commands. The downside is that both sides have to be running SSH 8.2+.