Hardening guides on sshaudit.com include unsupported algorithms and redundancies

[JuliusBairaktaris]

Hey,

the hardening guides on https://www.sshaudit.com/hardening_guides.html#ubuntu_22_04_lts use algorithms that are not currently supported by OpenSSH, and some algorithms are set twice.

For example, the line GSSAPIKexAlgorithms gss-curve25519-sha256-,gss-group16-sha512- includes algorithms that are not supported by OpenSSH.

Additionally, the line KexAlgorithms: curve25519-sha256 is redundant because curve25519-sha256@libssh.org is the same algorithm with a different name.

Suggested Configuration: I would suggest the following configuration for OpenSSH:

KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256

Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

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

HostKeyAlgorithms sk-ssh-ed25519-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256

CASignatureAlgorithms sk-ssh-ed25519@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256

HostbasedAcceptedAlgorithms sk-ssh-ed25519-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-256

PubkeyAcceptedAlgorithms sk-ssh-ed25519-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-256

Additional Information: This configuration is also used in my Powershell Script for hardening OpenSSH in Windows (Guide in the Wiki will follow soon).

[jtesta]

For example, the line GSSAPIKexAlgorithms gss-curve25519-sha256-,gss-group16-sha512- includes algorithms that are not supported by OpenSSH.

These algorithms are indeed supported on Ubuntu 22.04:

$ cat /etc/os-release 
PRETTY_NAME="Ubuntu 22.04.4 LTS"
[...]

$ ssh -Q kex-gss
[...]
gss-group16-sha512-
[...]
gss-curve25519-sha256-

Additionally, the line KexAlgorithms: curve25519-sha256 is redundant because curve25519-sha256@libssh.org is the same algorithm with a different name.

From a cryptographic standpoint that may (or may not) be true, but from a protocol perspective, these are distinct. And Ubuntu 22.04 includes support for them both:

$ ssh -Q kex
[...]
curve25519-sha256
curve25519-sha256@libssh.org
[...]

Since I didn't know what the difference was between them from a cryptographic standpoint, I treat them as effectively equivalent in the hardening guides (that is, they are listed one immediately after the other). This allows clients supporting just one of them to still use a key exchange based on Curve25519.

If anyone can produce evidence that one of them is cryptographically weak, though, I'd be happy to remove it from the guides and start flagging it in the tool.

[JuliusBairaktaris]

You're right, I apologize for the incorrect information earlier about gss-group16-sha512- and gss-curve25519-sha256- not being supported I should have verified that on a proper VM instead of WSL. OpenSSH does not support these algorithms directly, which led to my mistaken conclusion. https://ssh-comparison.quendi.de/comparison/kex.html

Regarding the difference between curve25519-sha256 and curve25519-sha256@libssh.org from a cryptographic standpoint, RFC 8731 clarifies that they are effectively equivalent in terms of security properties. The name change was primarily driven by standardization efforts and conventions rather than any underlying cryptographic differences.

To encourage users to adopt the standardized naming convention, I think it would be beneficial to mark curve25519-sha256@libssh.org) as non-standard by ssh-audit. To push users to switch to the standardized name.

I would suggest the following OpenSSH configuration to serve as a system independent configuration:

KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256

Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

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

HostKeyAlgorithms sk-ssh-ed25519-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256

CASignatureAlgorithms sk-ssh-ed25519@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256

HostbasedAcceptedAlgorithms sk-ssh-ed25519-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-256

PubkeyAcceptedAlgorithms sk-ssh-ed25519-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-256

[jtesta]

I apologize for the incorrect information earlier

No problem.

To encourage users to adopt the standardized naming convention,

I think this is outside the scope of ssh-audit. Our main goals revolve around security auditing and hardening. It would be up to the rest of the industry to determine what algorithm name formats to standardize on. For us, we're interested in maximizing compatibility within the subset of high-security configurations. Which means including support for curve25519-sha256@libssh.org if platforms are still using it.

[JuliusBairaktaris]

I think this is outside the scope of ssh-audit. Our main goals revolve around security auditing and hardening. It would be up to the rest of the industry to determine what algorithm name formats to standardize on. For us, we're interested in maximizing compatibility within the subset of high-security configurations. Which means including support for curve25519-sha256@libssh.org if platforms are still using it.

Makes sense to me.