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

Use Only FIPS 140-2 Validated MACs

Restrict the SSH server to FIPS 140-2 validated Message Authentication Codes (MACs) based on SHA-2: hmac-sha2-512-etm@openssh.com, hmac-sha2-256-etm@openssh.com, hmac-sha2-512, hmac-sha2-256.

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 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 2 standards

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

FIPS-approved cryptographic hash functions must be used to protect the integrity of the SSH session. The only SSHv2 MAC algorithms meeting this requirement are based on SHA-2. Legacy MACs (MD5, RIPEMD-160, 96-bit truncations) are considered broken and can be exploited in downgrade and man-in-the-middle attacks to tamper with or decrypt the SSH tunnel, capturing credentials and session data. For systems that must operate in a FIPS mode, using non-validated MACs is also a direct compliance violation.

What Pavois checks

Pavois runs sshd -T and matches the effective macs line against the validated SHA-2 list. sshd -T prints the configuration the daemon actually resolved, after every Include, Match block and drop-in in /etc/ssh/sshd_config.d/, so a weak MAC re-enabled by a forgotten drop-in is caught. Reading /etc/ssh/sshd_config directly would miss those includes and report a false negative.

describe command('sshd -T') do
  its('stdout') { should match(/^macs\s+hmac\-sha2\-512\-etm@openssh\.com,hmac\-sha2\-256\-etm@openssh\.com,hmac\-sha2\-512,hmac\-sha2\-256$/i) }
end

How to verify it is applied

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

macs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256

No other algorithm should appear in the list.

Inspect & investigate

SSH negotiation and connection events are logged to /var/log/auth.log (or journalctl -u ssh). A client offering only weak MACs will be refused with a message such as no matching MAC found, visible in those logs and useful to spot legacy clients before tightening the policy.

Remediation

Pavois's harden plan writes the MACs directive (sshd_setting resource) with the validated SHA-2 value into the SSH drop-in configuration and reloads sshd. Apply it with pavois harden apply. The change takes effect on the next connection; existing sessions are not dropped.

Pavois applies this with its own harden engine, the plan below, not a shell script:

directiveMACs
notifyaction: reload, service: ssh.service
resourcesshd_setting
valuehmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256
verifysshd -t -f %{path}
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

Removing legacy MACs can break very old SSH clients, embedded devices or scripted automation that only speak MD5/96-bit MACs. Before applying, inventory your clients (modern OpenSSH already prefers SHA-2) and keep a second console or out-of-band access open. Apply the new macs line, then open a fresh SSH session in a new terminal to confirm you can still authenticate before closing the original one, this avoids locking yourself out.

Standards mapping

StandardReferenceTypeVersionConfidence
CIS5.1.15directper OS, see the benchmark tablehigh
DISA STIGUBTU-24-100830directper 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