← All rules
SOCLE-CLD-SSH-031// SSHmediumeffective runtime

Use Only FIPS 140-2 Validated Ciphers

Restrict sshd Ciphers to the FIPS-validated set, ordered strongest first: aes256-ctr,aes256-gcm@openssh.com,aes128-ctr,aes128-gcm@openssh.com.

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.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Ubuntu 22.04CIS 3.0.0
One check, maps to 1 standard

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

Only FIPS 140-2 validated symmetric ciphers may protect the SSH session. Unapproved or weak ciphers cannot be relied on for confidentiality or integrity, so traffic protected by them may be readable or tamperable. The list is pinned strongest to weakest (aes256-ctr, aes256-gcm@openssh.com, aes128-ctr, aes128-gcm@openssh.com) because sshd negotiates the first server cipher the client also offers, ordering guarantees the strongest mutually-supported algorithm is chosen.

What Pavois checks

Pavois asserts that the effective sshd -T output lists exactly ciphers aes256-ctr,aes256-gcm@openssh.com,aes128-ctr,aes128-gcm@openssh.com, 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, reading sshd_config alone can miss a drop-in or policy that re-adds a weak cipher.

describe command('sshd -T') do
  its('stdout') { should match(/^ciphers\s+aes256\-ctr,aes256\-gcm@openssh\.com,aes128\-ctr,aes128\-gcm@openssh\.com$/i) }
end

How to verify it is applied

Run sshd -T | grep -i '^ciphers'. Expected output:

  • ciphers aes256-ctr,aes256-gcm@openssh.com,aes128-ctr,aes128-gcm@openssh.com

Inspect & investigate

The negotiated cipher per session is logged at VERBOSE level in /var/log/auth.log (Debian/Ubuntu) or journalctl -u ssh. Clients offering only non-approved ciphers are refused with no matching cipher found, also visible there.

Remediation

No automated remediation for this rule, apply it manually following the standard.

Impact & precautions

Restricting the cipher list can lock out older clients that lack these algorithms (legacy SSH libraries, embedded devices, old jump hosts). Before applying, inventory the clients that connect to this host and confirm they support AES-CTR/AES-GCM; validate with sshd -t and keep a second session open. Note a system-wide crypto policy (e.g. Ubuntu/RHEL update-crypto-policies) may also constrain or override the effective list.

Standards mapping

StandardReferenceTypeVersionConfidence
DISA STIGUBTU-22-255050directper OS STIG releasehigh

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.

Sources & references