Enable Use of Strict Mode Checking
Makes sshd refuse key-based login when file ownership or permissions are too loose, by setting StrictModes yes.
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
With StrictModes yes, before accepting a key-based login sshd checks the ownership and permissions of the user's home directory, ~/.ssh, and authorized_keys. If those are group- or world-writable, another local user could insert their own key and log in as the victim. Strict mode blocks that path, closing a common local privilege-escalation and account-takeover vector caused by misconfigured permissions.
What Pavois checks
Pavois reads the effective strictmodes value from sshd -T, the daemon's resolved configuration. A file scan of /etc/ssh/sshd_config could miss a value set in an Included drop-in under /etc/ssh/sshd_config.d/, sshd -T reflects exactly what the running daemon enforces.
describe command('sshd -T') do
its('stdout') { should match(/^strictmodes\s+yes$/i) }
endHow to verify it is applied
Run sudo sshd -T | grep -i strictmodes. The expected output is strictmodes yes.
Inspect & investigate
When strict mode rejects a login, sshd logs a permissions/ownership warning (e.g. Authentication refused: bad ownership or modes for directory ...) in /var/log/secure (RHEL family); follow with journalctl -u sshd -f.
Remediation
pavois harden apply sets the sshd_setting directive strictmodes to yes in a managed drop-in, validates it with sshd -t -f %{path}, then notifies a reload of the ssh service so the check is enforced without dropping live sessions.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| directive | strictmodes |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | yes |
| verify | sshd -t -f %{path} |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
With StrictModes no, a world- or group-writable ~/.ssh lets any local user plant a key and impersonate the account, a real takeover risk. Enabling strict mode is safe and is the default on most systems. Precaution: if some users currently have loose permissions on their home directory, ~/.ssh, or authorized_keys, their key-based logins will start failing once strict mode is on, fix them first (chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, correct ownership). The reload preserves your current SSH session, so there is no lockout risk for an already-connected admin.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| NIST | 3.1.12 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | 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.