Openssh 8.2

30-04-2021 by



  1. Openssh 8.2p1 Ubuntu
  2. Openssh Release Notes

OpenSSH 8.2 released

Notably from the changelog: It is now possible1 to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the 'ssh-rsa' public key signature algorithm by default in a near-future release. OpenSSH 8.2 does include new support for FIDO U2F tokens, including the Yubikey. Note that both the client and server must have OpenSSH 8.2 in order to work this way. However, Yubikeys support many other methods to secure SSH authentication besides FIDO U2F. Including PIV, PGP, and OTP methods, which support much older versions of OpenSSH. Crypto-policies is a component in Red Hat Enterprise Linux 8, which configures the core cryptographic subsystems, covering the TLS, IPsec, DNSSEC, Kerberos protocols, and the OpenSSH suite. It provides a small set of policies, which the administrator can select using the update-crypto-policies command. System-wide SSH configuration information is stored in the /etc/ssh/ directory as described in Table 8.1, “System-wide configuration files”.User-specific SSH configuration information is stored in /.ssh/ within the user's home directory as described in Table 8.2, “User-specific configuration files”.

Posted Feb 15, 2020 11:43 UTC (Sat) by Sesse (subscriber, #53779)
Parent article: OpenSSH 8.2 releasedDeprecation of older key exchange types is all fun and games, but not when you have older switches you want to SSH to (and that are no longer getting new OS releases). What's the real alternative? Surely SHA-1 can't be so broken that telnet is better :-)

(“-oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc” frequently helps, but not in all cases.)

(Log in to post comments)

OpenSSH 8.2 released

Posted Feb 15, 2020 12:51 UTC (Sat) by pizza (subscriber, #46) [Link]

...Surely a $50K barrier to entry (rsa-sha1) is better than forcing us to use a mechanism whose barrier to entry is $0 (ie telnet)

(See also: https with SSL3/TLS1.0/TLS1.1 vs plain http)

OpenSSH 8.2 released

Posted Feb 15, 2020 14:22 UTC (Sat) by qyliss (guest, #131684) [Link]

SSL3/TLS1.0/TLS1.1 leave users of modern protocols open to downgrade attacks. Using those means making everybody liable to downgrade attacks, unlike plain HTTP. They’re not just being disabled out of spite.

OpenSSH 8.2 released

Posted Feb 15, 2020 17:53 UTC (Sat) by pizza (subscriber, #46) [Link]

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

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

Accessing no-longer-secure systems

Posted Feb 15, 2020 22:14 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

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.

Accessing no-longer-secure systems

Posted Feb 15, 2020 23:56 UTC (Sat) by pizza (subscriber, #46) [Link]

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.

OpenSSH 8.2 released

Posted Feb 16, 2020 3:49 UTC (Sun) by mirabilos (subscriber, #84359) [Link]

Full ACK.

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

OpenSSH 8.2 released

Posted Mar 3, 2020 0:53 UTC (Tue) by rodgerd (guest, #58896) [Link]

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.

OpenSSH 8.2 released

Posted Feb 15, 2020 13:42 UTC (Sat) by dumain (subscriber, #82016) [Link]

The alternative to OpenSSH 8.2 isn't Telnet but a second,older, copy of ssh under a different name.

Keeping an extra copy of ssh around might require a bit of work but is better to require people to do extra work to be insecure than requiring extra work to be secure. If you want to you can even rename the older ssh binary to telnet.

OpenSSH 8.2 released

Posted Feb 16, 2020 6:25 UTC (Sun) by djm (subscriber, #11651) [Link]

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.

OpenSSH 8.2 released

Posted Feb 16, 2020 9:57 UTC (Sun) by Sesse (subscriber, #53779) [Link]

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

OpenSSH 8.2 released

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

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

OpenSSH 8.2 released

Posted Feb 16, 2020 19:18 UTC (Sun) by Sesse (subscriber, #53779) [Link]

OpenSSH 8.2 released

Posted Feb 20, 2020 8:08 UTC (Thu) by smurf (subscriber, #17840) [Link]

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

Posted Feb 20, 2020 14:32 UTC (Thu) by smoogen (subscriber, #97) [Link]

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

Posted Feb 22, 2020 8:58 UTC (Sat) by niner (subscriber, #26151) [Link]

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

Posted Feb 22, 2020 16:11 UTC (Sat) by smoogen (subscriber, #97) [Link]

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

Posted Mar 3, 2020 0:55 UTC (Tue) by rodgerd (guest, #58896) [Link]

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

Posted Mar 3, 2020 3:32 UTC (Tue) by pizza (subscriber, #46) [Link]

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

OpenSSH 8.2 released

Posted Feb 15, 2020 11:43 UTC (Sat) by Sesse (subscriber, #53779)
Parent article: OpenSSH 8.2 releasedDeprecation of older key exchange types is all fun and games, but not when you have older switches you want to SSH to (and that are no longer getting new OS releases). What's the real alternative? Surely SHA-1 can't be so broken that telnet is better :-)

(“-oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc” frequently helps, but not in all cases.)

(Log in to post comments)

OpenSSH 8.2 released

Posted Feb 15, 2020 12:51 UTC (Sat) by pizza (subscriber, #46) [Link]

...Surely a $50K barrier to entry (rsa-sha1) is better than forcing us to use a mechanism whose barrier to entry is $0 (ie telnet)

(See also: https with SSL3/TLS1.0/TLS1.1 vs plain http)

OpenSSH 8.2 released

Posted Feb 15, 2020 14:22 UTC (Sat) by qyliss (guest, #131684) [Link]

SSL3/TLS1.0/TLS1.1 leave users of modern protocols open to downgrade attacks. Using those means making everybody liable to downgrade attacks, unlike plain HTTP. They’re not just being disabled out of spite.

OpenSSH 8.2 released

Posted Feb 15, 2020 17:53 UTC (Sat) by pizza (subscriber, #46) [Link]

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

Accessing no-longer-secure systems

Posted Feb 15, 2020 22:14 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

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

Accessing no-longer-secure systems

Posted Feb 15, 2020 23:56 UTC (Sat) by pizza (subscriber, #46) [Link]

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.

OpenSSH 8.2 released

Posted Feb 16, 2020 3:49 UTC (Sun) by mirabilos (subscriber, #84359) [Link]

Full ACK.

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

OpenSSH 8.2 released

Posted Mar 3, 2020 0:53 UTC (Tue) by rodgerd (guest, #58896) [Link]

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.

OpenSSH 8.2 released

Posted Feb 15, 2020 13:42 UTC (Sat) by dumain (subscriber, #82016) [Link]

The alternative to OpenSSH 8.2 isn't Telnet but a second,older, copy of ssh under a different name.

Keeping an extra copy of ssh around might require a bit of work but is better to require people to do extra work to be insecure than requiring extra work to be secure. If you want to you can even rename the older ssh binary to telnet.

OpenSSH 8.2 released

Posted Feb 16, 2020 6:25 UTC (Sun) by djm (subscriber, #11651) [Link]

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.

OpenSSH 8.2 released

Posted Feb 16, 2020 9:57 UTC (Sun) by Sesse (subscriber, #53779) [Link]

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

OpenSSH 8.2 released

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

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

OpenSSH 8.2 released

Posted Feb 16, 2020 19:18 UTC (Sun) by Sesse (subscriber, #53779) [Link]

OpenSSH 8.2 released

Posted Feb 20, 2020 8:08 UTC (Thu) by smurf (subscriber, #17840) [Link]

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

Posted Feb 20, 2020 14:32 UTC (Thu) by smoogen (subscriber, #97) [Link]

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

Posted Feb 22, 2020 8:58 UTC (Sat) by niner (subscriber, #26151) [Link]

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

Posted Feb 22, 2020 16:11 UTC (Sat) by smoogen (subscriber, #97) [Link]

Openssh 8.2p1 Ubuntu

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

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

Posted Mar 3, 2020 0:55 UTC (Tue) by rodgerd (guest, #58896) [Link]

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

Posted Mar 3, 2020 3:32 UTC (Tue) by pizza (subscriber, #46) [Link]

Openssh Release Notes

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




Winamp Vst
Sophos Xg Central Management

Comments are closed.