Use Only Strong Key Exchange algorithms
Disable weak SSH key-exchange (KexAlgorithms) methods, the SHA-1-based Diffie-Hellman groups (diffie-hellman-group1-sha1, diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha1), so only strong KEX algorithms remain.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
Key exchange is the method by which the client and server agree on the cryptographic keys protecting the session. SHA-1-based Diffie-Hellman groups (especially the 1024-bit group1) are weak: SHA-1 is collision-prone and small DH groups are within reach of well-resourced attackers (Logjam-style precomputation). A compromised key exchange lets an attacker in a man-in-the-middle position derive the session keys, decrypt the tunnel and steal credentials. Removing these legacy KEX algorithms forces use of strong curves (Curve25519) and SHA-2 groups.
What Pavois checks
Pavois runs sshd -T and matches the effective kexalgorithms line, which begins with the - exclusion of the weak SHA-1 groups. sshd -T prints the daemon's resolved configuration, after all Include, Match blocks and drop-ins, so a weak KEX re-enabled downstream is caught. Reading /etc/ssh/sshd_config directly would miss those includes and produce a false negative.
describe command('sshd -T') do
its('stdout') { should match(/^kexalgorithms\s+sntrup761x25519\-sha512@openssh\.com,curve25519\-sha256,curve25519\-sha256@libssh\.org,ecdh\-sha2\-nistp256,ecdh\-sha2\-nistp384,ecdh\-sha2\-nistp521,diffie\-hellman\-group\-exchange\-sha256,diffie\-hellman\-group16\-sha512,diffie\-hellman\-group18\-sha512,diffie\-hellman\-group14\-sha256$/i) }
endHow to verify it is applied
Run sshd -T | grep -i '^kexalgorithms' and confirm none of diffie-hellman-group1-sha1, diffie-hellman-group14-sha1 or diffie-hellman-group-exchange-sha1 appears in the resolved list. The effective line should match:
kexalgorithms -diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
Inspect & investigate
SSH negotiation events are logged to /var/log/auth.log (or journalctl -u ssh). A client able to use only a weak KEX is refused with Unable to negotiate ... no matching key exchange method found, which reveals legacy clients before enforcement.
Remediation
This rule has no automated harden plan in Pavois yet, so it must be applied manually: add KexAlgorithms -diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 to a drop-in under /etc/ssh/sshd_config.d/, validate with sshd -t, then reload with systemctl reload ssh.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| directive | KexAlgorithms |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256 |
| verify | sshd -t -f %{path} |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Excluding SHA-1 DH groups can prevent connections from very old SSH clients or appliances that support no modern curve or SHA-2 group. Before applying, check your client fleet (recent OpenSSH negotiates Curve25519 by default) and keep a second session or console open. Validate the config with sshd -t before reloading, then open a fresh SSH session in a new terminal to confirm access before closing the original, avoiding a lockout.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.7, 5.1.12 | direct | per OS, see the benchmark table | high |
| PCI DSS | 2.2.7 | supporting | 4.0.1 | medium |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.