Hacker News Reader

Comment by stavros | Hacker News Reader

This is unnecessarily complicated to do for SSH, since SSH (and the Yubikey) support FIDO2:

https://www.stavros.io/posts/u2f-fido2-with-ssh/

Yes, they do - but it requires both client support and server support to work. Older servers can’t do it, and for example the provided openssh version with windows doesn’t support it either. And adding GPG keys to a yubikey may be interesting to people using pass or similar password managers.

Certainly, but if both server and client supports it (Ubuntu has shipped with it by default for a few versions now), it's much, much easier to use it instead.

Not everything is a server. And not everything that even is a server can be upgraded.

"Normal" SSH keys will work for (pretty much) all systems that support SSH. And the ones that don't will certainly never support U2F.

> "Normal" SSH keys will work for (pretty much) all systems that support SSH.

And even that is not true in all cases. I still regularly encounter devices that only support 2048 bit RSA and nothing beyond that. /glances in ubiquis direction.

Yeah, I glossed over several details here.

Since I use Yubikeys in PIV mode with PKCS#11, it works just fine to use its 2048bit RSA.

If the option is 2048bit RSA, passwords, or software keys, then I know what I prefer.

It's worth to add that the private key file generated by `ssh-keygen -t` is not the actual private key, but a reference (like a handle) to the private key stored on the secure device https://www.yubico.com/blog/github-now-supports-ssh-security...

I've been using this but you can't switch the security key, unfortunately. Just upgraded my security key and now I'm stuck with the old key.

Yes, the practical impossibility of recovering a private key from a security device is a feature. This implies you can't change security devices without changing public keys.

Yeah, I just didn't know how it works; didn't know it was stored there, but assumed it was just encrypted with the secret in the key, i.e. in the presence of the old and the new security key, it could be decrypted and re-encrypted with the new one.

Not every Yubikey supports the resident keys. All my Yubikey 5 keys have too old firmware, which AFAIK cannot be updated, so this is not a viable solution for lots of people even if they own the hardware. GPG just works, and can be used for many other things while one's at it already.

I agree with you in general, but saying "GPG just works" in a post about a long guide on how to set it up seems iffy.

Not just a little iffy, it's more like "Nope, even if I get this working, this is not something I can recommend supporting for everyone on the team."

For business, it's a better deal to buy new Yubikeys that support FIDO2 then it is to support GPG on Yubikeys.

Absolutely. We're trialling this for our SSH bastion server. The security keys don't need any setup at all, which makes it much easier to handle backups and replacements.

Let me rephrase: GPG is possible to get working, the resident keys are not, regardless of the amount of setup. Though the other comment seems to suggest it might not be the case, so maybe there is hope.

The first revision Yubikey 5’s support resident keys, just not the credential management API, at least that is my understanding.

I had a Yubikey 5 with the first firmware revision and resident keys worked fine.

Do you have any documents on how I can use them in such case?

You should be able to just use a website that uses resident keys (such as Microsoft Passwordless login). I don't think the UI is any different, it's just that the key will actually get stored on the device.

Because the first firmware revision lacks the credential management API, there's no way to list the resident keys on the device or to delete individual keys. The only way to delete resident keys AFAIK is to reset the FIDO2 application on the key.

A couple points:

- The guide was mostly written before that was possible

- Many servers are slow to update to newer distro versions with newer openSSH versions. I still need to access at least one server which can’t support it yet. (And just one which doesn’t support it forces me to use the GPG approach so that it’s the same key everywhere.)

- the guide also tells you to use the new approach if it’s available to you :)

- GPG is still used for some other things, like signing git commits

I didn't mean my comment as criticism of the guide, just to say that the method it uses is very complicated, and that there's a simpler one. If you can't use the simpler one, this is a great guide!

Note that the linked guide describes the cruise/air/tilt version that includes a master identity scheme. Most people don't need to do something as complicated as all that and can just use the defaults for everything and in the end dump the private keys to the device.

Backing up the secret key material is still an issue with FIDO2.

I think idea is that you don't backup secret key material.

You should add multiple keys to your logins and have a "backup" key which is separate one.

Especially when you lose physical key, you want to have different one and revoke lost one asap.

The same with private keys generated on a device - private key should stay on the device on which it was generated and never copied. If you need access from a different device you generate private key on another device and transfer public key only to be added to account.

Which in turn also makes physical keys that you can connect to different devices a bit more convenient as private key never leaves key and is not directly accessible by laptop that it is connected to.

In PGP land it makes a lot of sense to back up your secret key material. That is because the passphrase that the user enters encrypts the secret key material. So a strong passphrase means you can backup that key anywhere and everywhere ... and probably should.

Having a strong passphrase makes things a lot simpler. A classic convenience vs security tradeoff...

It'll be 10-20 years, at least, before this is a valid replacement.

I can't use it to log in to my routers and other SSH gear, and don't expect to for the lifetime of the hardware.

With OpenSSH U2F it'll be decades before you won't ALSO need a more traditional key. That or use passwords (brrr)

Not everyone supports FIDO2 server-side, though. GitHub only added support in last May, for example.

Reply on news.ycombinator.com