Disable SSH Support for User Known Hosts
Forces sshd to ignore each user's ~/.ssh/known_hosts file by setting IgnoreUserKnownHosts 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
When host-based authentication is allowed, a user-controlled ~/.ssh/known_hosts file can be used to bypass the system's trusted host list. By setting IgnoreUserKnownHosts yes, sshd trusts only the system-wide /etc/ssh/ssh_known_hosts, so an attacker who plants entries in a user's file cannot authenticate as another user or impersonate a trusted host. It is a defense-in-depth measure that guarantees a remote login still requires a password even if host-based trust is misconfigured elsewhere.
What Pavois checks
Pavois asserts the runtime value by parsing sshd -T, which prints the fully resolved effective configuration. Reading /etc/ssh/sshd_config alone would miss values set in Included drop-ins under /etc/ssh/sshd_config.d/ or contextual Match blocks, sshd -T reflects exactly what the running daemon enforces.
describe command('sshd -T') do
its('stdout') { should match(/^ignoreuserknownhosts\s+yes$/i) }
endHow to verify it is applied
Run sudo sshd -T | grep -i ignoreuserknownhosts. The expected output is ignoreuserknownhosts yes.
Inspect & investigate
Authentication attempts and the relevant decisions are recorded by sshd in /var/log/secure (RHEL family), follow them live with journalctl -u sshd -f. Host-based authentication rejections appear there with messages referencing the user's known_hosts handling.
Remediation
pavois harden apply sets the sshd_setting directive ignoreuserknownhosts to yes in a managed drop-in, validates the file with sshd -t -f %{path}, then notifies a reload of the ssh service so the change takes effect without dropping existing sessions.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| directive | ignoreuserknownhosts |
|---|---|
| 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
Leaving IgnoreUserKnownHosts at the default no lets users seed their own trusted-host entries, which can be abused to bypass host-based access controls and impersonate trusted machines. Applying the rule is low-risk: it only affects host-based authentication and does not change password or public-key logins. Precaution: if you rely on host-based authentication (HostbasedAuthentication yes) with per-user known_hosts, those flows will break, migrate those entries into the system-wide /etc/ssh/ssh_known_hosts first. The reload (not restart) keeps your current SSH session alive, so there is no lockout risk.
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.