Show HN: Yubikey-agent – an easy to use Go ssh-agent for YubiKeys | Hacker News Reader

Show HN: Yubikey-agent – an easy to use Go ssh-agent for YubiKeys

github.com

152 pointsFiloSottile52 comments

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

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.

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

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

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

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

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 use it with PKCS#11 mode and can't confirm some of the drawbacks the author mentions under Alternatives:

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

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?

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.

Hmm, gpg-agent has worked nicely for me.

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)

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.

Keep it simple.. once the key is on an yubikey it's not going anywhere..

The biggest risk is that I loose the key.

> The biggest pain is that I have to reconfigure when I switch yubikey.

This is planned to be fixed in GnuPG 2.3.

Wow, how?

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 :)

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

If you want to check it yourself https://dev.gnupg.org/T4695

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?

You have 2 physical Yubikeys and no backup anywhere else.

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)

Windows users might find this useful: https://github.com/drduh/YubiKey-Guide

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.

https://framkant.org/2016/10/use-a-smart-card-or-hsm-to-secu...

> The UX of this solution is poor

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.

You can also use Trezor.io instead of Yubikey for ssh login. https://blog.trezor.io/openssh-with-fido2-and-trezor-e565c22...

Advantage of Trezor is that it has better backup system and can be used for more things in general.

Would it be possible (or would patches be accepted) to talk to the GnuPG scdaemon instead? This would let me use gpg-agent to sign and encrypt.

I want to mention a Yubikey alternative that runs on open-source firmware and software: OnlyKey [1]

It has an onlykey-agent that works as an SSH agent [2]. It doesn't work as a GPG agent yet though, they are reportedly working on it.

[1] https://onlykey.io/ [2] https://docs.crp.to/onlykey-agent.html

You may want to read the recent discussion on HN about OnlyKey before using one:

https://news.ycombinator.com/item?id=21884184

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.

I'm really excited about the next SoloKey coming out soon.

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.

Based on their blog post they are working on supporting PIV / PKCS#11 which would support SSH Keys and AES operations.

https://solokeys.com/blogs/news/update-on-our-new-and-upcomi...

[Edit removed it to be more specific]

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

Reply on news.ycombinator.com