Weird KexAlgorithms recommendations in hardening guide

[cjwatson]

https://www.ssh-audit.com/hardening_guides.html has perplexing recommendations for KexAlgorithms. It includes a bunch of entries there, such as gss-curve25519-sha256-, which sshd_config(5) does not document as being valid for KexAlgorithms, but only for GSSAPIKeyAlgorithms. It may happen to work by luck, but it isn't guaranteed.

This is not only strange, but also harmful for multiple reasons:

• As I described in https://lists.debian.org/debian-devel/2024/04/msg00044.html, I intend to split out GSS-API key exchange support from Debian's main OpenSSH packages in Debian 14 (forky), and that change will eventually trickle down to Ubuntu and other Debian derivatives. As a result of your guide being widely-distributed, I'm probably going to have to do some cumbersome hacking to avoid the situation where anyone who's followed your recommendations will have a configuration file that specifies key exchange algorithms that sshd no longer knows about at all. Or maybe I'll just leave it broken to force them to adapt, due to the next point ... I'm not sure yet.
• OpenSSH is not likely to introduce new key exchange algorithms that are less secure than the existing ones. That means that specifying a positive list of permitted key exchange algorithms like this implicitly means opting out of any future improved algorithms that OpenSSH introduces. Since your intent appears to be to remove weak algorithms, you should instead use the method for removing items from the default set by beginning the list with a "-" character, which has been supported since OpenSSH 7.5; that would also be clearer by being more explicit about which algorithms you're removing. This applies to all of CASignatureAlgorithms, Ciphers, HostbasedAcceptedAlgorithms, KexAlgorithms, MACs, and PubkeyAcceptedAlgorithms (though unfortunately not to GSSAPIKexAlgorithms - I only just noticed that discrepancy).

[rm-td]

Following intently as ssh is the bane of my life between Windows native, putty, linux, 3rd party eg even Nessus unable to establish in certain cirmstances.

IMHO The above a nice take. I agree on the approach of " use the method for removing items from the default set by beginning the list with a "-" character".

Example on Debian 12 is that, according to the currently-published ssh-audit scripts at time of writing (30JAN25) I can reduce the entire "hardened" config to 4 lines and get all green except for firewall throttling.

KexAlgorithms -ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

MACs -hmac-sha1,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,umac-128@openssh.com,umac-64-etm@openssh.com,umac-64@openssh.com

Ciphers -chacha20-poly1305@openssh.com

HostKeyAlgorithms -ecdsa-sha2-nistp256

This config might be different in other OS based upon ciphers and suites supported.
Further note in MY config at this time per above I have chosen the cipher suites I dont want rather than rely on OS-specific remediation.

Its a hard job, respect to all.

[rm-td]

The plot thickens. The openssh daemon will not interpret multiple statements of the same type, it processes the first one in the list. So if we follow the a method of "use the method for removing items from the default set by beginning the list with a "-" character" we do not appear to have the capability to have a corresponding list beginning with a "+" character.

ie this

KexAlgorithms -ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
KexAlgorithms +sntrup761x25519-sha512@openssh.com

does not work. Where the first line is favoured, using the methodology we can either remove deprecated or not have certain supported-but-not-enabled-by-default items.

Why is this a problem? What happens if one does wish to enable sntrup761x25519-sha512@openssh.com which according to the openssh documentation is available but disabled by default since version 8.5 and only enabled by default since a later version than the RHEL repo and its variants support. There is no backport.
Following the suggested methodology I can't do this. On my Debian 12 deployment as above I can, as Debian 12 supports sntrup761x25519-sha512@openssh.com by default.

Which brings us full-circle to a statically-configured line as per the hardening guide.
Help a brain-frazzled limey out here!

[cjwatson]

It's true that this is a potential issue. If you need that (for OpenSSH versions >= 8.5 and < 8.9) then I think your only choice is to spell out the full list. But that is an exceptional case and IMO it would be better treated as such, rather than always spelling out the full list for the sake of the occasional exception.

[cjwatson]

From a brief check, it looks as though no currently-supported release of either Debian or Ubuntu is affected by the problem outlined above: I'm just going by versions rather than doing a more detailed check, but it looks as though they all either have no sntrup761x25519-sha512@openssh.com key exchange algorithm at all or else they have it enabled by default.

[rm-td]

Indeed its enabled by default. RHEL/variants have stuff to workaround given the vendor-published signed verified RPM is a little behind. Debian 12 is version 9.2 which has bits enabled by default.
Perhaps the onus striving towards secure by design is on Redhat to update or backport functionality? Bah. Cheers for thinking on my notes above.

[perkelix]

@jtesta I'd really like to see ssh-audit get around migrating its configs to disabling deprecated algorithms, rather than the current method of specify a whitelist, as proposed by @cjwatson above. Could we have this done soon?

[jtesta]

Yep. I'm currently doing behind-the-scenes work in getting a new release completed. I haven't forgotten about this.

[jtesta]

https://www.ssh-audit.com/hardening_guides.html has perplexing recommendations for KexAlgorithms. It includes a bunch of entries there, such as gss-curve25519-sha256-, which sshd_config(5) does not document as being valid for KexAlgorithms, but only for GSSAPIKeyAlgorithms. It may happen to work by luck, but it isn't guaranteed.

@cjwatson : I appreciate the heads up! Moving forward, I won't include gss-* in KexAlgorithms for new platforms. I suppose leaving them in the existing guides isn't hurting anything, though.

That means that specifying a positive list of permitted key exchange algorithms like this implicitly means opting out of any future improved algorithms that OpenSSH introduces. Since your intent appears to be to remove weak algorithms, you should instead use the method for removing items from the default set by beginning the list with a "-" character

The existing whitelisting strategy has never caused a problem because none of the supported platforms ever upgraded OpenSSH in the middle of their lifecycle. (At least... I've never noticed this; if I'm wrong, definitely let me know!) On the other hand, RedHat's maintainer has made some... interesting choices... and could very well add custom patches to enable poor algorithms.

Do you have plans for pushing new releases of OpenSSH to existing installations of, say, Debian 13? If so, that would be a practical reason to switch to a blacklist instead.

[perkelix]

OpenSSH 10 has been back-ported to at least one older Debian release. Additionally, the non-@ssh variant of a kex was added to an earlier release.

The key reason why policies should blacklist older algorithms, rather than whitelist specific ones, is that it makes the same configuration portable across several releases.

[cjwatson]

Do you have plans for pushing new releases of OpenSSH to existing installations of, say, Debian 13? If so, that would be a practical reason to switch to a blacklist instead.

We wouldn't do that for all users, but as @perkelix said, I backported OpenSSH 10.0 to Debian 12 as an opt-in backport, and I may do similar things in future.

More importantly, Debian users generally expect to be able to upgrade to new Debian releases in place rather than reinstalling, and Debian supports that very well. If ssh-audit's strategy is assuming that users of Debian 13 won't eventually upgrade to Debian 14 without remembering that they need to reapply a new version of an ssh-audit guide ... well, that doesn't sound like a valid assumption to me.

[jtesta]

@cjwatson : Ok, I suppose switching to a blacklist for Debian makes sense, then. Might you happen to know if Ubuntu also back-ports OpenSSH versions?

[cjwatson]

Might you happen to know if Ubuntu also back-ports OpenSSH versions?

It wouldn't be done in a way that's pushed to users by default, and there don't seem to be any official backports for currently-supported Ubuntu releases, but there is a backports channel with similar rules as in Debian and it's certainly possible that somebody might decide to do so.

[perkelix]

@jtesta I really don't see why you make this a Debian-specific issue. The key point is not whether backports are available. It is to have upward-valid hardening configs. Blacklisting deprecated algorithms is sustainable since we merely disable what we definitely don't want and leave the door open for more, while whilelisting explicitly excludes newer algorithms that appear along the line. Blacklisting also means that fewer release-specific hardening configs are needed.