Hacker News Reader

Comment by stavros | Hacker News Reader

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+.

View on HN

> 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.

Ubuntu LTS does support it, and it's already out. Servers are set to have the upgrade offered in a month, IIRC.

Half of our servers are Ubuntu 14.04, the rest 18.04.

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

It's in 20.04, the next LTS, which will be an upgrade option to you in a month.

Yes - but it works smoothly: https://cryptsus.com/blog/how-to-configure-openssh-with-yubi...

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.

Why can't they? Using a PIN works fine with my key.

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.

Hmm, does the token provide signing without the PIN? That seems like a very big oversight, but mine doesn't sign in without the PIN.

What can someone with the handle do? They can't log in without the USB token, right?

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...

I use gpg-agent, but I agree it is often a pain. I will probably switch to U2F + SSH once more servers have OpenSSH 8.2.

Do you know if this already works with GitHub?

I don't, and I doubt it (there would be an announcement), but it will be great when it does.

> Do you know if this already works with GitHub?

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

Packet type 51 is SSH_MSG_USERAUTH_FAILURE (see https://www.ietf.org/rfc/rfc4250.html#section-4.1.2).

Sounds really easy but how do you backup this key to another Yubikey? Or do you simply have two, and always add two keys to each server?

The latter, yes. That way it's trivial to revoke one if it gets lost.

You can also look into Trezor - it has much better backup system, among other advatages compared to yobikey

https://blog.trezor.io/openssh-with-fido2-and-trezor-e565c22...

Can you register multiple devices for the same SSH key, so you have a backup in case one gets lost or breaks?

No, but why do you need to? Just add multiple keys to all hosts.

Oh right, that's effectively the same thing...

Why not just add the keys from each device to your machines? Doing secure key transfer between hardware tokens is way more complicated.

Can such a key be used as an aws key?

The public key? Sure, if the AWS SSH server supports the key type.

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

Reply on news.ycombinator.com