Use Only FIPS 140-2 Validated Key Exchange Algorithms
Restrict sshd KexAlgorithms to the FIPS-validated set, ordered strongest first: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256.
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
The SSH key exchange establishes the session keys that protect all subsequent traffic; a weak KEX undermines the whole connection regardless of the cipher. Only FIPS-approved algorithms may be offered. The list is pinned strongest to weakest (ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256) because sshd selects the first server algorithm the client also supports, ordering ensures the strongest mutually-supported KEX is negotiated and excludes weak or deprecated exchanges (e.g. SHA-1 or small DH groups).
What Pavois checks
Pavois asserts that the effective sshd -T output lists exactly kexalgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256, in that order. Querying the live daemon reflects the value after all Include directives, /etc/ssh/sshd_config.d/ drop-ins and any system-wide crypto policy are merged, a file scan can miss a drop-in or policy that re-adds a weak KEX.
describe command('sshd -T') do
its('stdout') { should match(/^kexalgorithms\s+ecdh\-sha2\-nistp256,ecdh\-sha2\-nistp384,ecdh\-sha2\-nistp521,diffie\-hellman\-group\-exchange\-sha256$/i) }
endHow to verify it is applied
Run sshd -T | grep -i '^kexalgorithms'. Expected output:
kexalgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256
Inspect & investigate
KEX negotiation is logged at VERBOSE level in /var/log/auth.log (Debian/Ubuntu) or journalctl -u ssh. A client offering only non-approved algorithms is refused with Unable to negotiate ... no matching key exchange method found, visible in the same logs.
Remediation
No automated remediation for this rule, apply it manually following the standard.
Impact & precautions
Pinning the KEX list can break connections from clients that don't share one of these algorithms, notably modern clients configured for curve25519-sha256 only, or very old clients stuck on SHA-1 exchanges. Inventory your clients first and confirm overlap, validate with sshd -t, keep a second session open, and remember a system-wide crypto policy may further constrain the effective list.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| NIST | AC-17(2) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| DISA STIG | UBTU-22-255060 | direct | per OS STIG release | high |
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.