OpenSSH Security and SHA1

[Eldin Hadzic]

We should enhance Security by disabling SHA1 or, if not possible (older Clients) by changing the KexAlgorithms, Ciphers and MACs order.

For e.g. by :

1. If we add Support for older Clients we should change this:

#### OpenSSH Security ####

KexAlgorithms <email address hidden>,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
Ciphers <email address hidden>,<email address hidden>,<email address hidden>,aes256-ctr,aes192-ctr,aes128-ctr
MACs <email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,<email address hidden>

2. If we just Support new Clients we should change this :

[...]
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
[...]

#### OpenSSH Security ####

KexAlgorithms <email address hidden>,diffie-hellman-group-exchange-sha256
Ciphers <email address hidden>,<email address hidden>,<email address hidden>,aes256-ctr,aes192-ctr,aes128-ctr
MACs <email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,<email address hidden>

For more Information about my report go here:

https://github.com/scaleway/image-ubuntu/pull/35

[Seth Arnold (seth-arnold)]

Hello Eldin, you're right that it is time to begin migrating away from SHA-1 in default OpenSSH configurations. However there is some historical baggage in parts of the launchpad infrastructure that prevented upgrading algorithms earlier. (Strictly speaking, the defaults aren't tied to launchpad but a configuration that doesn't allow developers to work out of the box is less than ideal.)

Some related bugs that might help explain the situation:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1445620
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1445624
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1445625

A site with many general guidelines that may influence more than just default keysize and hash selections: https://stribika.github.io/2015/01/04/secure-secure-shell.html

And, of course, whatever we select should be tested against Cisco gear, since there's always a bug or two with every openssh configuration change that prevents people from logging into or using Cisco equipment.

Colin, is it feasible to start making algorithm changes yet?

Thanks

[Colin Watson (cjwatson)]

Not yet. I'm actively working on the relevant bits of Launchpad infrastructure, and will upgrade to OpenSSH 7.1p1 after that. I *don't* intend to vary algorithm choices from upstream configuration, but 7.1 is already a fair bit better.

[Eldin Hadzic (eldin)]

Hello Colin, Hello Seth,

thank you for your response. I completely understand the situation with launchpad and Cisco Equipment :-).

I already know the page https://stribika.github.io/2015/01/04/secure-secure-shell.html, but still thank you.

[Eldin Hadzic (eldin)]

Just a note:

"I and @stribika have the same point of view (https://stribika.github.io/2015/01/04/secure-secure-shell.html) [...]"

"I tend to agree with @aimxhaisse. Don't you think it would be preferable to open a bug report on Ubuntu side (https://bugs.launchpad.net/ubuntu/), see what they answer and follow their advices?"

Have a nice Weekend,

Eldin Hadzic

[Seth Arnold (seth-arnold)]

Thank you Colin, that's great news.

I think we should have a discussion about which algorithms to deprecate, when, for the whole distribution. I'd like a consistent approach to when we stop supporting md5/sha-1/rc4 etc. Of course different protocols may have different threat models so it may not be appropriate to apply a single blanket rule for any algorithm, but supporting 16.04 LTS in 2021 makes me think that we ought to be willing to cut the algorithms known to be weak today.

OpenSSH's choices for e.g. 7.1 will probably make a lot of sense for today but may make less sense in five years, when we're still supporting 7.1 but they've moved on. Other upstreams may not be as reliable as OpenSSH, either, and second guessing their choices may make more sense.

Thanks

[Colin Watson (cjwatson)]

Backporting algorithm tightening may make sense, but I don't want to end
up in a situation where users are trying to deal with interoperability
issues but none of the upstream docs make sense. If we're advocating
specific changes that upstream aren't currently already considering, we
should take that up with upstream.

[Eldin Hadzic (eldin)]

Hello Colin, Hello Seth,

Seth that sounds great :-). I totally agree you.

Colin and that´s the same Problem we had on Scaleway, but I am sure that we are finding a solution :-).

I would love to participate @ the discussion.

Have a nice day,

Eldin Hadzic