OpenSSH 8.2 released

Posted Feb 15, 2020 13:53 UTC (Sat) by nix (subscriber, #2304)
Parent article: OpenSSH 8.2 released

This release removes support for the ssh-rsa key algorithm

A near-future release may do that. This one is only removing support for *certificates* signed with ssh-rsa. Since certificate support was added long after much better algorithms were not only available but the default in SSH, it seems likely that very few certificates are affected, and even fewer users.

Myself, I'm much more excited about the U2F support. With PIV support on every hardware token I've tried still a flaming dumpster fire: the keys work fine, but the software is a wreck, with OpenSC and gpg-agent *still* both failing when obviously-useful things happen like you removing your key because you're walking away from the machine for five minutes *without* killing all your SSH sessions first... I'm looking forward to U2F support in OpenSSH as something that avoids this entire mass of horrible software trouble areas and just works, while keeping my key material sealed away in special-purpose hardware where it belongs.

(Side note: even though the private key on the local machine is useless without the token, I'm still planning to passphrase it simply because that gives me a little extra protection: an attacker would then need physical presence -- because of the need to touch the key for key operations -- *and* access to a machine with the private key half, *and* knowledge of the passphrase. Without the latter, someone who simply stole my keyring and laptop could use the SSH keys on the laptop freely.)

OpenSSH 8.2 released

Posted Feb 15, 2020 20:13 UTC (Sat) by karkhaz (subscriber, #99844) [Link] (4 responses)

An extension of this is to actually use two factors, i.e. a passphrase-encrypted private key on your laptop together with a token. sshd has an AuthenticationMethods configuration option that can be given two factors to be tried serially.

This gives more resilience against only one of your factors being stolen. Suppose that you have Laptop and Workstation, from which you connect to Server, and Laptop and Workstation each have their own local private key. Server requires two factors. So in Server's authorized_keys file, you would add the public keys of Laptop and Workstation, the token's public key, and a 'backup' token public key (backup token is kept in a safe).

Then, if your laptop gets stolen, you can ssh into Server using Workstation + token and delete the laptop public key from Server's authorized_keys. If you lose the token, you can use the backup token plus your laptop.

OpenSSH 8.2 released

Posted Feb 15, 2020 21:04 UTC (Sat) by nix (subscriber, #2304) [Link] (3 responses)

An extension of this is to actually use two factors, i.e. a passphrase-encrypted private key on your laptop together with a token. sshd has an AuthenticationMethods configuration option that can be given two factors to be tried serially.

Yes indeed -- I'm currently using YubiKeys in OTP mode combined with an on-disk OpenSSH ChallengeResponse key to do just this. "AuthenticationMethods publickey,keyboard-interactive" works like a charm.

My goal is to migrate from that to a scheme that doesn't rely on a YubiKey-specific implementation and that doesn't depend on an authentication server which is, ah... well, almost all of them are fairly dreadful and/or unmaintained other than Joey Hess's (as in "needed local patches to support libykclient 2.15, released in 2015, without which all authentication attempts fail, the upstream maintainer never responded" sort of unmaintained). It's a shame, really -- I like YubiOTP, it's nice and transparent and easy to see that you're getting a different authenticator every time, while FIDO2 is... not like that. (Hm, I suppose I could use *both*, but that seems kind of pointless, since they both prove ownership of the exact same hardware token. So it probably is better to go to a passphrased SSH key to prove knowledge of the passphrase -- i.e., human identity -- with the key on the token, to prove possession of the token. Note that this passphrase is given on the *client* -- AuthenticationMethods is not required at all, since the only method needed is ChallengeResponse.)

... ugh, my YubiKey is too old to support ed25519 keys? But I only bought it a few months ago! Argh. I wish they didn't have non-upgradeable closed-source firmware on those things. Maybe I should migrate to some other key, but I do need HMAC-SHA1 generation as well (for disk encryption passphrases) and most non-YubiKey keys can't do that.

OpenSSH 8.2 released

Posted Feb 16, 2020 18:05 UTC (Sun) by abartlet (subscriber, #3928) [Link]

Another approach I've used (with some older Yubikey IIs that do not support SSH keys) is to challenge-response a passphrase via the OATH HMAC-SHA1 facility to get the 'real' passphrase for my on-disk SSH keys.

But UF2 support seems much neater.

OpenSSH 8.2 released

Posted Feb 18, 2020 4:26 UTC (Tue) by justincormack (subscriber, #70439) [Link] (1 responses)

I don't think any Yubikey supports ed25519 yet, sadly. Their HSM product does.

OpenSSH 8.2 released

Posted Feb 19, 2020 16:34 UTC (Wed) by nix (subscriber, #2304) [Link]

Very new ones do, at least for OpenPGP: <https://support.yubico.com/support/solutions/articles/150...>. But whether that applies to U2F as well is less clear (and I'm not buying a key to fix this only to find out that the answer is "no".)

OpenSSH 8.2 released

Posted Feb 16, 2020 17:58 UTC (Sun) by abartlet (subscriber, #3928) [Link]

One way to avoid using gpg-agent for this, for a Yubikey at least, is to have OpenSSH use it directly.

The gpg-agent route looked way too complex when I set up my new linux.conf.au swag Yubikey, but I found this guide and it worked on Ubuntu 18.04 (once I found the right library path for the .opensc-pkcs11.so):

https://github.com/jamesog/yubikey-ssh

It shocks me that the main guides are all for what seems a much more complex route via GPG.

That said, I've been seriously impressed with the usability of U2F and am really excited to see that come to SSH.

OpenSSH 8.2 released

Posted Feb 16, 2020 19:17 UTC (Sun) by josh (subscriber, #17465) [Link] (4 responses)

> Without the latter, someone who simply stole my keyring and laptop could use the SSH keys on the laptop freely.

...after breaking the full-disk encryption on your laptop, or stealing it while you had it running and unlocked?

OpenSSH 8.2 released

Posted Feb 17, 2020 21:21 UTC (Mon) by rodgerd (guest, #58896) [Link] (1 responses)

Note that the dock-over-wireless exposes PCIe-over-wireless so exposes DMA-over-wireless. There are already proof-of-concept hacks for this.

So "someone nearby stealing your keys" is not as unlikely as you might like to think.

OpenSSH 8.2 released

Posted Feb 18, 2020 1:57 UTC (Tue) by josh (subscriber, #17465) [Link]

Sure, but it's a defense-in-depth measure. Someone would need to steal your physical keyring *and* break into your laptop while it was running.

OpenSSH 8.2 released

Posted Feb 19, 2020 16:35 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Stealing it while it's suspended appears to suffice (at least, it doesn't ask me for a passphrase of any kind on unsuspending). And since I hardly ever shut it down...

OpenSSH 8.2 released

Posted Feb 19, 2020 17:57 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

I have suspend hooked up to lock my screen, so at least *that* password should be in the way. Though the race between the lock screen getting up and the CPU being powered down does get lost maybe 5% of the time :/ .