← All rules
SOCLE-CLD-FSP-160// File permissionsmediumpersistent config

Verify Permissions on SSH Server Public *.pub Key Files

Ensures the /etc/ssh directory (holding the SSH host keys and *.pub files) is not writable or executable by group or other, protecting host-key integrity.

Checked against the content of a persistent configuration file, the source of truth that survives reboots.

A pass proves? running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 4 standards

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 /etc/ssh directory holds the SSH host key pairs, including the public *.pub host keys that clients use to authenticate the server. If a public host key file (or the directory containing it) is writable by a non-privileged user, an attacker could replace it to facilitate man-in-the-middle attacks or undermine host-key trust, compromising the SSH service. The directory must be owned by root with no write/execute for group or other and no special bits, so host-key material cannot be altered by unauthorised users.

What Pavois checks

Pavois reads the effective mode of the /etc/ssh directory and asserts no write/execute for group or other and no setuid/setgid/sticky bits (public *.pub files are world-readable by design; the protection is against writing them). Guarded by only_if { file('/etc/ssh').exist? }. Checking the live directory inode reflects what an attacker could actually modify at runtime, regardless of what the package shipped.

describe command("find /etc/ssh -maxdepth 1 -name '*.pub' -perm /133 2>/dev/null") do
  its('stdout.strip') { should eq '' }
end

How to verify it is applied

Run stat -c '%a %U %G' /etc/ssh. The expected output is 755 root root or stricter: no write bit for group or other. The public keys themselves should be 644 root root and the private host keys 600 root root (check with ls -l /etc/ssh/ssh_host_*).

Inspect & investigate

stat /etc/ssh and ls -l /etc/ssh/*.pub show the current modes. The host key fingerprints presented to clients can be checked with ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub. SSH service events are in journalctl -u ssh / /var/log/auth.log (Debian/Ubuntu) or journalctl -u sshd / /var/log/secure (RHEL family). Changes appear in /var/log/audit/audit.log if /etc/ssh is watched.

Remediation

No automated harden plan is defined for this rule yet, so apply it manually: chown root:root /etc/ssh then chmod 0755 /etc/ssh, and ensure the public keys are chmod 0644 /etc/ssh/*.pub (the private host keys must stay 0600).

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

commandfind /etc/ssh -maxdepth 1 -name '*.pub' -exec chmod 0644 {} + 2>/dev/null; true
namesshd-pubkey-perms
not_iftest -z "$(find /etc/ssh -maxdepth 1 -name '*.pub' -perm /133 2>/dev/null)"
resourceexec
pavois harden plan local

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

Impact & precautions

If /etc/ssh is writable by a non-root user, an attacker can swap the host keys and set up a man-in-the-middle, or replace the daemon's keys to break client trust and trigger host-key-mismatch warnings. Precautions: keep the directory readable/traversable (0755) and the public keys world-readable (0644), clients and the daemon need them; do not make the directory 0700 or 0600 the .pub files, as that can disrupt key handling. Tightening only the write bits is non-disruptive to existing SSH sessions.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R50direct2.0high
CIS2.2.6, 5.1.3, 5.1.5directper OS, see the benchmark tablehigh
NIST3.1.13, AC-17(a), AC-6(1), CM-6(a)supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium
PCI DSS2.2.6supporting4.0.1medium

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