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,[email protected],diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

MACs -hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,[email protected],[email protected],[email protected]

Ciphers [email protected]

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,[email protected],diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
KexAlgorithms [email protected]

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 [email protected] 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 [email protected] 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 [email protected] 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.