← All rules
SOCLE-CLD-FSP-094// File ownershipmediumfilesystem state

Verify Owner on SSH Server Configuration Files

Ensures the SSH drop-in directory /etc/ssh/sshd_config.d is owned by root (uid 0).

Checked against a path’s metadata, mode, owner, group, SUID/SGID.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 2 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

On modern Ubuntu, /etc/ssh/sshd_config ends with Include /etc/ssh/sshd_config.d/*.conf, so drop-in files in that directory override the main policy. This is exactly the surface a file-based scanner misses. If a non-root user owns /etc/ssh/sshd_config.d, they can drop in a .conf that re-enables root login or weakens authentication, silently overriding a hardened main config. Restricting ownership to root (uid 0) ensures only the superuser can introduce SSH policy overrides.

What Pavois checks

Pavois asserts that the live directory /etc/ssh/sshd_config.d has owner uid 0, skipped via only_if if it does not exist. This rule embodies Pavois's edge: file-based scanners check only sshd_config and miss the Included drop-ins that can silently override it. Pavois reads the effective owner of the override directory from the filesystem, catching drift that OVAL/oscap would not even look at.

only_if { file('/etc/ssh/sshd_config.d').exist? }
describe file('/etc/ssh/sshd_config.d') do
  its('uid') { should eq 0 }
end

How to verify it is applied

Run stat -c '%U %u' /etc/ssh/sshd_config.d. Expected output: root 0. To cover the drop-ins too, run find /etc/ssh/sshd_config.d -not -user root, it should print nothing.

Inspect & investigate

Ownership has no continuous log; query it with stat /etc/ssh/sshd_config.d. The effect of a rogue drop-in is visible by comparing the running policy with sshd -T against your expected baseline. SSH service and config-load errors appear in /var/log/auth.log or via journalctl -u ssh.

Remediation

No automated harden plan is defined, so apply it manually: chown root:root /etc/ssh/sshd_config.d and, for the override files, chown root:root /etc/ssh/sshd_config.d/*.conf.

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

ownerroot
path/etc/ssh/sshd_config.d
resourcefile
pavois harden plan local

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

Impact & precautions

A non-root owner of this directory can silently override your hardened SSH policy via a drop-in, potentially re-enabling remote root login. Restoring root ownership is safe and does not affect current sessions. Precaution: after fixing ownership, run sshd -t and confirm the running policy with sshd -T; keep file modes restrictive and keep a backup session open before reloading sshd.

Standards mapping

StandardReferenceTypeVersionConfidence
CIS5.1.1directper OS, see the benchmark tablehigh
NISTAC-17(a), AC-6(1), CM-6(a)supporting800-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.

Sources & references