Use Only FIPS 140-2 Validated MACs
Restrict sshd MACs to the FIPS-validated SHA-2 set, ordered strongest first: hmac-sha2-512,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-256-etm@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.
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 Message Authentication Code (MAC) protects the integrity of each packet; a weak MAC lets an attacker tamper with traffic or replay packets undetected. Only FIPS-approved hash functions are acceptable, and for SSHv2 that means the SHA-2 family, MD5 and SHA-1 based MACs must not be offered. The list is pinned strongest to weakest (hmac-sha2-512, hmac-sha2-512-etm@openssh.com, hmac-sha2-256, hmac-sha2-256-etm@openssh.com) so the strongest mutually-supported MAC is negotiated; the -etm (encrypt-then-MAC) variants are preferred for their stronger construction.
What Pavois checks
Pavois asserts that the effective sshd -T output lists exactly macs hmac-sha2-512,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-256-etm@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, a file scan can miss a drop-in or policy that re-adds a weak (SHA-1/MD5) MAC.
describe command('sshd -T') do
its('stdout') { should match(/^macs\s+hmac\-sha2\-512,hmac\-sha2\-512\-etm@openssh\.com,hmac\-sha2\-256,hmac\-sha2\-256\-etm@openssh\.com$/i) }
endHow to verify it is applied
Run sshd -T | grep -i '^macs'. Expected output:
macs hmac-sha2-512,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-256-etm@openssh.com
Inspect & investigate
MAC negotiation is logged at VERBOSE level in /var/log/auth.log (Debian/Ubuntu) or journalctl -u ssh. A client offering only non-approved MACs is refused with Unable to negotiate ... no matching MAC found, visible in the same logs.
Remediation
No automated remediation for this rule, apply it manually following the standard.
Impact & precautions
Restricting MACs can lock out clients that only offer SHA-1 or umac-based MACs (older SSH libraries, embedded devices). Inventory the clients reaching this host and confirm SHA-2 support before applying, validate with sshd -t, keep a second session open, and note a system-wide crypto policy may further constrain the effective list.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| DISA STIG | UBTU-22-255055 | 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.