5 ms·

The release drops support for some old protocol versions and outdated/broken ciphers. No more sshv1, RC4, rsa512, ... Is there anyone inconvenienced by this?

by jabot 9y ago

peterwwillis 9y ago
Blowfish gone will impact a good deal of orgs that were using it for performance reasons
- keeperofdakeys 9y ago
  Due to hardware acceleration, AES based ciphers on a modern computer can blow arcfour and blowfish out of the water. https://blog.famzah.net/2015/06/26/openssh-ciphers-performance-benchmark-update-2015/ https://blog.famzah.net/2015/06/26/openssh-ciphers-performan...
  - deleted 9y ago
    [deleted]
  - peterwwillis 9y ago
    Yes, but that isn't really the point. Legacy and embedded computers without AES instructions don't get those gains, so they use blowfish. And those with blowfish configured will either A) fail to connect entirely due to "Ciphers: blowfish-cbc" excluding all others, or B) fall back to another cipher that's slow on that system. Things are going to break, is my point.
- jedisct1 9y ago
  AES and ChaCha20 are faster.
  - crest 9y ago
    AES is slower for bulk encryption than Blowfish on old CPUs (at least those with enough data cache for the Blowfish tables).
jlgaddis 9y ago
Well, I updated my laptop a little bit ago and after a reboot I couldn't SSH into it from my workstation. The cause ended up being because I explicitly set "MACs" in sshd_config and still had hmac-ripemd160 (and -etm) in there. Technically, yeah, I was inconvenienced but, meh, not really. It took all of three minutes to troubleshoot and fix and it was entirely my fault for not reading the changelog before upgrading first. Again, this was just a laptop and this would not have affected anything in production (I'm not sure if any other distros stay that up-to-date).
majewsky 9y ago
Yes, the sshd on my private servers refused connections after the upgrade because I had hmac-ripemd160-etm in my MACs selection in the sshd_config. Thankfully, I have a scheduled auto-update job in place, so I just pushed an updated configuration package to my personal repo and they all grabbed and installed it, thus restoring my access.
alltakendamned 9y ago
only people with a very bad taste in cipher algorithms will be. Those protocols have been dead for a _long_ time.
INTPenis 9y ago
I remember disabling some insecure kex algorithms last year and suddenly some co-workers were complaining. Apparently they hadn't updated their putty in many years. One update and they could login again. :) That situation will likely repeat itself with this latest upgrade.
simias 9y ago
At work I connect to old embedded hardware running ancient versions of dropbear. I already have to whitelist some deprecated algorithms to connect to them successfully (most notably SHA1 HMAC) so I'll probably struggle even more with this newer version. I guess it's time to build a newer version of dropbear. Not that I don't support their decision to drop support for these deprecated algorithms, it's our fault for running outdated software. Actually the only thing that annoys me in these release notes is: >Please note that the SHA256 signatures are base64 encoded and not hexadecimal (which is the default for most checksum tools). Then why not use hex? Neither GNU coreutil's sha256sum nor FreeBSD's sha256 supports outputting in base64. OpenBSD's sha256 has a '-b' switch for base64 but by default it's in hex as well. Is it really worth adding this pain on the user just to save 20 bytes?
YouKnowBetter 9y ago
The biggest losers are most likely: the bots. I update my sshd configs untill they're green [0] and love to see the bots fail with even establishing a connection. You can even distinguish the different bot families by their (limited) protocols. [0] https://github.com/arthepsy/ssh-audit https://github.com/arthepsy/ssh-audit
- mrsteveman1 9y ago
  Very nice tool, I hadn't seen that before thanks! There should be a service similar to Mozilla's TLS configuration generator[1], but for SSH. Mozilla does have a wiki page with modern and intermediate SSH configurations[2], but I'm not sure whether the advice is still current, and a configuration generator page would probably be more accessible. I wonder if they would be open to creating one. [1] https://mozilla.github.io/server-side-tls/ssl-config-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat... [2] https://wiki.mozilla.org/Security/Guidelines/OpenSSH https://wiki.mozilla.org/Security/Guidelines/OpenSSH
  - YouKnowBetter 9y ago
    Good point about the sshd_config generator. Who knows, people might even use it. As to the up to dateness of the Mozilla Guidelines: it is not. Just see the entry "UsePrivilegeSeparation sandbox" which has been deprecated since 7.5 [0] [0] https://www.openssh.com/txt/release-7.5 https://www.openssh.com/txt/release-7.5

The release drops support for some old protocol versions and outdated/broken ciphers. No more sshv1, RC4, rsa512, ... Is there anyone inconvenienced by this?

by jabot 9y ago

The release drops support for some old protocol versions and outdated/broken ciphers. No more sshv1, RC4, rsa512, ... Is there anyone inconvenienced by this?

peterwwillis 9y ago

Blowfish gone will impact a good deal of orgs that were using it for performance reasons

keeperofdakeys 9y ago
Due to hardware acceleration, AES based ciphers on a modern computer can blow arcfour and blowfish out of the water. https://blog.famzah.net/2015/06/26/openssh-ciphers-performance-benchmark-update-2015/ https://blog.famzah.net/2015/06/26/openssh-ciphers-performan...
- deleted 9y ago
  [deleted]
- peterwwillis 9y ago
  Yes, but that isn't really the point. Legacy and embedded computers without AES instructions don't get those gains, so they use blowfish. And those with blowfish configured will either A) fail to connect entirely due to "Ciphers: blowfish-cbc" excluding all others, or B) fall back to another cipher that's slow on that system. Things are going to break, is my point.
jedisct1 9y ago
AES and ChaCha20 are faster.
- crest 9y ago
  AES is slower for bulk encryption than Blowfish on old CPUs (at least those with enough data cache for the Blowfish tables).

jlgaddis 9y ago

Well, I updated my laptop a little bit ago and after a reboot I couldn't SSH into it from my workstation. The cause ended up being because I explicitly set "MACs" in sshd_config and still had hmac-ripemd160 (and -etm) in there. Technically, yeah, I was inconvenienced but, meh, not really. It took all of three minutes to troubleshoot and fix and it was entirely my fault for not reading the changelog before upgrading first. Again, this was just a laptop and this would not have affected anything in production (I'm not sure if any other distros stay that up-to-date).

majewsky 9y ago

Yes, the sshd on my private servers refused connections after the upgrade because I had hmac-ripemd160-etm in my MACs selection in the sshd_config. Thankfully, I have a scheduled auto-update job in place, so I just pushed an updated configuration package to my personal repo and they all grabbed and installed it, thus restoring my access.

alltakendamned 9y ago

only people with a very bad taste in cipher algorithms will be. Those protocols have been dead for a _long_ time.

INTPenis 9y ago

I remember disabling some insecure kex algorithms last year and suddenly some co-workers were complaining. Apparently they hadn't updated their putty in many years. One update and they could login again. :) That situation will likely repeat itself with this latest upgrade.

simias 9y ago

At work I connect to old embedded hardware running ancient versions of dropbear. I already have to whitelist some deprecated algorithms to connect to them successfully (most notably SHA1 HMAC) so I'll probably struggle even more with this newer version. I guess it's time to build a newer version of dropbear. Not that I don't support their decision to drop support for these deprecated algorithms, it's our fault for running outdated software. Actually the only thing that annoys me in these release notes is: >Please note that the SHA256 signatures are base64 encoded and not hexadecimal (which is the default for most checksum tools). Then why not use hex? Neither GNU coreutil's sha256sum nor FreeBSD's sha256 supports outputting in base64. OpenBSD's sha256 has a '-b' switch for base64 but by default it's in hex as well. Is it really worth adding this pain on the user just to save 20 bytes?

YouKnowBetter 9y ago

The biggest losers are most likely: the bots. I update my sshd configs untill they're green [0] and love to see the bots fail with even establishing a connection. You can even distinguish the different bot families by their (limited) protocols. [0] https://github.com/arthepsy/ssh-audit https://github.com/arthepsy/ssh-audit

mrsteveman1 9y ago
Very nice tool, I hadn't seen that before thanks! There should be a service similar to Mozilla's TLS configuration generator[1], but for SSH. Mozilla does have a wiki page with modern and intermediate SSH configurations[2], but I'm not sure whether the advice is still current, and a configuration generator page would probably be more accessible. I wonder if they would be open to creating one. [1] https://mozilla.github.io/server-side-tls/ssl-config-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat... [2] https://wiki.mozilla.org/Security/Guidelines/OpenSSH https://wiki.mozilla.org/Security/Guidelines/OpenSSH
- YouKnowBetter 9y ago
  Good point about the sshd_config generator. Who knows, people might even use it. As to the up to dateness of the Mozilla Guidelines: it is not. Just see the entry "UsePrivilegeSeparation sandbox" which has been deprecated since 7.5 [0] [0] https://www.openssh.com/txt/release-7.5 https://www.openssh.com/txt/release-7.5