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+.
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.
I'll wager that it's not gonna be in either of these releases.
You should specify which lts you're talking about with a distribution that releases every 6 months
What can someone with the handle do? They can't log in without the USB token, right?
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.
Do you know if this already works with GitHub?
It does not. From an `ssh -vvv firstname.lastname@example.org -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
I had problems pushing for solutions that used non-RSA public keys in my $dayjob because of this
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.
> The UX of this solution is poor: [...] and needs manual reloading every time the YubiKey is unplugged or the machine goes to sleep.
I never have to re-enter the PIN after sleep and can even unplug it for a while to use the port for HDMI output.
Still good to see some work in this space. Native OpenSSH support would be best of course.
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.
The biggest pain is that I have to reconfigure when I switch yubikey.
(Yes, I have multiple keys with the same gpg key on each)
The biggest risk is that I loose the key.
This is planned to be fixed in GnuPG 2.3.
Currently I understand that gpg records a card identifier. And my card doesn't have the same id.
I suppose it'll be a long time before this hits stable distros anyways. But nice to see improvements :)
If you want to check it yourself https://dev.gnupg.org/T4695
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.
One way to achieve it is by generating it on a RAM disk and throwing it away, once it's on both Yubikeys. I blogged about it here https://blog.snapdragon.cc/2019/04/27/using-a-yubikey-to-sec... (for macOS)
Not surprising if you ask me, have you installed an applet for it? Do latest Yubikey even allow installing applets? Why are you using PIV for this?
I was using https://github.com/philipWendland/IsoApplet with OpenSC and smartcards since 2016, no issues.
Advantage of Trezor is that it has better backup system and can be used for more things in general.
It has an onlykey-agent that works as an SSH agent . It doesn't work as a GPG agent yet though, they are reportedly working on it.
[Edit removed it to be more specific]