LWN: Comments on "OpenSSH 8.2 released"

OpenSSH 8.2 released

pizza — Tue, 03 Mar 2020 03:32:03 +0000

So does this "real alternative" include a source of CapEx funding other than the droppings of spherical unicorns?

OpenSSH 8.2 released

rodgerd — Tue, 03 Mar 2020 00:55:09 +0000

If your switches are stuck on ancient, insecure algorithms and the vendor no longer supports them, they're insecure. So the "real alternative" would be upgrading to switches that are supported, not security theatre.

OpenSSH 8.2 released

rodgerd — Tue, 03 Mar 2020 00:53:57 +0000

It also means a pile of code lying around that can act as a rich source of vulnerabilities, particularly if it gets next-to-no-attention from developers on a day to day basis.

FIDO2 resident keys can be PIN protected

mathstuf — Mon, 02 Mar 2020 18:36:45 +0000

Yeah. The thing is that I have more than 2 physical keys to do this with. I have 2 on my keyring (one A, another C), backups of each of those, then emergency dupes for geographic backup. Probably overkill, but losing access to some of the accounts would be quite painful.

If there were some way to have one SSH key that can be unlocked by any of the physical keys (with a passphrase?), that'd be nice, but I don't think that's supported now?

FIDO2 resident keys can be PIN protected

nix — Sun, 01 Mar 2020 14:33:09 +0000

Assuming you're talking FIDO and not OTP, the easiest approach is just to generate two distinct SSH keys, one against each YubiKey, and put them both in authorized_keys etc. Of course if they're not resident keys that then means you have to remember to copy twice as many keys around...

OpenSSH 8.2 released

smoogen — Sat, 22 Feb 2020 16:11:16 +0000

The issue usually is that would require redesigning other hardware and networks and dealing with budgets that the sysadmin who is stuck trying to fix the perambulator on the wizbang does not have access to. By the time it does get fixed it will be 4-5 years from now and probably 1 or 2 reorgs. Usually the small device you are looking at is going to be under 'operational expenses' while the big hardware is 'capital expenses' and they come from different approval organizations.

If the sysadmin is lucky they can just keep a directory or VM of 'old' software which they fire up to deal with certain things. Otherwise they end up with having to keep a central noc machine running Potato or Woody which talks to all that hardware til finally some sort of filter does happen.

OpenSSH 8.2 released

niner — Sat, 22 Feb 2020 08:58:46 +0000

Well if you're running such equipment, you should be able to afford putting a gateway box in front of the machine running up-to-date software and have your machine only be connected to that box. It shouldn't be that hard to secure that meter of cable between them.

OpenSSH 8.2 released

smoogen — Thu, 20 Feb 2020 14:32:33 +0000

Embedded hardware inside of very expensive capex (say the melter on a steel-mill which is a $10 million minimum replacement or some textile mill or plastic extruder or in a hospital a giant MRI device) usually will be in service for 20 to 40 years. Even when the hardware is serviceble, it is assumed that it will need to interact with other parts which have not been upgraded.. so you keep whatever was done at the time of building for at least 20 years. That means all the hardware you finally got upgraded to have ssh in the last 20 years (versus telnet before) is locked with whatever SSL and SSH algorithms from when the base model was manufactured. So an industrial IT department is locked with needing multiple copies of browsers and tools to deal with these 'forced' upgrades..

And after a while, management looks at the costs and dictates to do what @pizza said was the lowest common denominator: turn off ssh/ssl and move back to http and telnet.

OpenSSH 8.2 released

smurf — Thu, 20 Feb 2020 08:08:57 +0000

Yes. I've got a managed switch (in a secure internal network!) that sports a 768bit RSA host key. There also are a bunch out there that want to use DSA keys. Ugh, but can't be helped.

Seriously, that level of backwards incompatibility is disappointing. Keeping an older release isn't always feasible either; these may have security bugs or compiler incompatibilities that require significant efort to work around.

Keep the old (client) code behind an "-o insecure-old-server=true" flag which refuses to talk to new servers (so it can't be the default) but don't remove it entirely. PLEASE.

OpenSSH 8.2 released

mathstuf — Wed, 19 Feb 2020 17:57:58 +0000

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

OpenSSH 8.2 released

nix — Wed, 19 Feb 2020 16:35:25 +0000

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

nix — Wed, 19 Feb 2020 16:34:21 +0000

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

justincormack — Tue, 18 Feb 2020 04:26:54 +0000

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

OpenSSH 8.2 released

josh — Tue, 18 Feb 2020 01:57:28 +0000

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

rodgerd — Mon, 17 Feb 2020 21:21:42 +0000

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.

Bye bye RSA keys?

mgedmin — Mon, 17 Feb 2020 17:40:06 +0000

Thank you for clearing that up!

FIDO2 resident keys can be PIN protected

mathstuf — Sun, 16 Feb 2020 20:53:53 +0000

> But chances are you only use maybe 1-2 SSH keys anyway, so resident is reasonable for that.

Eh. I have something like a dozen keys. It's one per use case, so if something happens, keys are restricted to their realm of access anyways. I'm looking forward to being able to use my Yubikeys for SSH, but need to make a strategy first (also need to figure out how effectively enabling my backup keys at the same time is going to work).

OpenSSH 8.2 released

Sesse — Sun, 16 Feb 2020 19:18:30 +0000

Yup. HP 2650, for instance.

OpenSSH 8.2 released

josh — Sun, 16 Feb 2020 19:17:20 +0000

> 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

josh — Sun, 16 Feb 2020 19:15:47 +0000

Are there any devices that support SSH and RSA but don't support key lengths of 1024 or greater?

OpenSSH 8.2 released

abartlet — Sun, 16 Feb 2020 18:05:59 +0000

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

abartlet — Sun, 16 Feb 2020 17:58:50 +0000

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

lobachevsky — Sun, 16 Feb 2020 10:46:11 +0000

> * sshd(8): add an Include sshd_config keyword that allows including additional configuration files via glob(3) patterns.

I think this is a great quality of life improvement. I can finally just put in some drop in changes to the distro defaults.

Bye bye RSA keys?

cjwatson — Sun, 16 Feb 2020 09:59:29 +0000

djm answered before I did and with more authority. But to explain in a bit more detail: authenticating yourself using an RSA key involves signing a message with that key to prove that you own it. RSA signatures normally work by first hashing the plaintext message with some hash function and then applying the RSA algorithm to the result. The hash function can be basically anything reasonable, but it needs to be agreed by both parties. From this you can see that there doesn't need to be any particular link between hash function and key size.

Part of the SSH authentication protocol involves agreeing on mutually-acceptable parameters, such as the key signature algorithm; as a result you may well find different algorithms being used depending on the client/server combination.

OpenSSH 8.2 released

Sesse — Sun, 16 Feb 2020 09:57:05 +0000

There are (already) limitations on minimum RSA key lengths that you cannot get around without a recompile.

OpenSSH 8.2 released

djm — Sun, 16 Feb 2020 06:27:14 +0000

I plan to add support for PIN-protected U2F keys for openssh-8.3. Hang around on the development mailing lists if you want to check it out sooner.

OpenSSH 8.2 released

djm — Sun, 16 Feb 2020 06:25:25 +0000

No alternative is needed - the weak algorithms aren't being removed so you can enable them (e.g. "ssh -oCiphers=+ssh-rsa ...") without needing anything remotely custom.

Bye bye RSA keys?

djm — Sun, 16 Feb 2020 06:22:36 +0000

The signature algorithm doesn't relate to the key size, though OpenSSH will refuse RSA keys <1024 bits. Practically, you should use at least 2048 bit keys (this is the default for ssh0-keygen).

All existing ssh-rsa keys can be used with the newer rsa-sha2-256/512 signature types. Whether these are supported though is down to the ssh client and server in question, and the easiest way to find out whether both offer those algorithms is to try the recipe in the release notes ("ssh -oHostkeyAlgorithms=-ssh-rsa")

OpenSSH 8.2 released

mirabilos — Sun, 16 Feb 2020 03:49:08 +0000

Full ACK.

I’ll also be running into this (AIUI it’s about server keys, not about user keys) and very annoyed.

Accessing no-longer-secure systems

pizza — Sat, 15 Feb 2020 23:56:46 +0000

No, the most practical / least disruptive approach is to disable https altogether, and go back to plain http with plaintext credentials.

Mission accomplished, I guess.

Deprecation makes sense even though in theory there is no problem

tialaramex — Sat, 15 Feb 2020 22:48:37 +0000

It's the same thinking as for the Web PKI prohibiting SHA-1 years back. A cryptographic hash makes certain promises, SHA-1 is broken and can't fulfil some of those promises. Continuing to rely on the bits that don't seem broken yet is a bad gamble, for which you will pay very dearly if you guess wrong. So don't guess.

OpenSSH has some of the same safeguards as the Web PKI. The values to be signed (and which thus an attacker must guess when constructing their collision) are randomly chosen by somebody else. So _if_ everything works as intended an attacker has essentially no chance to successfully use any type of collision against you. But the necessity of using truly random values often escapes people, it's the kind of thing that is often disrupted by other seemingly minor security problems - and so we should avoid depending on it as much as possible.

In the Web PKI X.509's Serial Number field is required to be chosen randomly (if you ever looked at the Serial Number on a certificate you've got that's why the number was crazy). OpenSSH's hand rolled certificate format was designed much later and so it has an explicit "nonce" field which is defined as to be filled out with random data. But in both cases of course things can go wrong, better not to tempt fate.

FIDO2 resident keys can be PIN protected

tialaramex — Sat, 15 Feb 2020 22:31:11 +0000

If you have a FIDO2 compliant Security Key it can do "resident keys" and local second factor. For example Yubico's current model Security Key (with the numeral 2 prominent in the plastic case) offers this. The cheapest FIDO products don't do FIDO2, but if this feature is essential to you then you should spend a bit more and insist on FIDO2.

In this case you need a PIN which just like your GPG scenario doesn't get transmitted anywhere, as well as possession of the hardware, two factors. By default OpenSSH will only store one such resident key in the Security Key labelled with the "ssh:" URL protocol (a web site might write https://lwn.net/ here)

For web sites resident keys are annoying because that's a finite resource (Yubico doesn't say for their cheapest Security Key how many residential credentials can exist, but on the fancier product it's 25), maybe be I'd be OK using one for my bank but not for Facebook or Amazon or whatever - whereas FIDO is deliberately designed so that cheap FIDO keys can mint an effectively unlimited number of completely independent authentication tokens for non-resident keys and it makes sense to use those for even discardable low value accounts like a web forum. But chances are you only use maybe 1-2 SSH keys anyway, so resident is reasonable for that.

Accessing no-longer-secure systems

tialaramex — Sat, 15 Feb 2020 22:14:43 +0000

Probably the most practical / least disruptive approach is to have a proxy whose purpose is to manage this differential for you.

The proxy would present as a modern service (modern protocols and key support) but behind the scenes simply connect to the real backend using older insecure protocols and keys.

This way the insecurity is limited to those who consciously choose to use the proxy that doesn't deliver security. I guess this could either be an appliance one purchases (with lets hope a longer support lifetime than the devices you've had problems with) or software.

OpenSSH 8.2 released

nix — Sat, 15 Feb 2020 21:06:30 +0000

In my experience, when you unplug the key, gpg-agent gets very unhappy and refuses to consider using it again when you plug the key back in: you have to kill -9 it to get it to go away. (This may be specific to particular brands of keys, if as I suspect it's a libccid bug or something like that under the covers.)

OpenSSH 8.2 released

nix — Sat, 15 Feb 2020 21:04:16 +0000

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

karkhaz — Sat, 15 Feb 2020 20:13:42 +0000

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

pbonzini — Sat, 15 Feb 2020 20:06:53 +0000

U2F support is nice because the U2F fobs are cheaper, but the existing GPG authentication subkey is better in my opinion. It provides 2FA since you need the PIN to unlock the card, sharing your public key also becomes super easy, and it's also possible to forward the card (for any of signing, decryption and further authentication) to the host your SSH-ing to.

OpenSSH 8.2 released

luto — Sat, 15 Feb 2020 20:03:42 +0000

That’s an awkward solution to say the least. Encrypting the wrapped blob is of dubious value — especially with NFC U2F devices, it’s easy to sniff.

Maybe I’ll ask the OpenSSL people to add something.

OpenSSH 8.2 released

tim_small — Sat, 15 Feb 2020 19:47:12 +0000

You can use the sshd config directive "AuthenticationMethods publickey,publickey" to require two public keys (from two authorized_keys lines), and use a Match block to place this restriction on just one user (or source ip range etc. etc.). It's not really clear from the release notes whether you can encrypt the portion of the U2F private key which is stored on the filesystem, but if you can, then that's probably a good alternative.

OpenSSH 8.2 released

pizza — Sat, 15 Feb 2020 17:53:43 +0000

Yep, and by all means, remove support for them on the _server_ side of things so they require up-to-date clients to speak.

But on the client side, there's a very long tail of crap we need to communicate with that will *never* see updates to TLS 1.2 or beyond. and it is highly delusional to pretend that there is no cost to replacing them.

By all means, have the clients COMPLAIN VERY LOUDLY or require special command line switches or whatever to speak with this older gear.

(The software for configuring the RAID controllers in two of my servers maxes out at TLS1.0, as does the https support in all of the network switches I have deployed. Granted, this stuff is all on private networks, but I don't want to have to keep around a VM with ancient software on it to administer things..)