Verify Group Ownership on SSH Server Private *_key Key Files
Ensures the SSH host private-key location /etc/ssh is owned by the dedicated ssh_keys group.
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
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 host private keys (/etc/ssh/ssh_host_*_key) prove the server's identity. If an unauthorized user reads a private host key, they can impersonate the host in a man-in-the-middle attack and silently capture sessions. On these distributions the keys are protected by the dedicated ssh_keys group combined with restrictive permissions; setting the correct group ownership on /etc/ssh is the basis of that protection.
What Pavois checks
Pavois reads the real owning group of /etc/ssh via InSpec's file resource and asserts group == 'ssh_keys'. It checks the effective ownership on disk, so a regenerated host key (e.g. after ssh-keygen -A or a re-provision) that landed with the wrong group is detected even when the deployment manifest still looks correct.
describe command('find /etc/ssh -name "ssh_host_*_key" -type f ! -group root ! -group ssh_keys 2>/dev/null') do
its('stdout.strip') { should eq '' }
endHow to verify it is applied
Run stat -c '%G' /etc/ssh (expected ssh_keys) and check the keys themselves: stat -c '%n %G %a' /etc/ssh/ssh_host_*_key, private keys should be group ssh_keys with mode 0640 (or 0600 root:root depending on the profile).
Inspect & investigate
Add an auditd watch, auditctl -w /etc/ssh -p wa -k sshd_keys, to record ownership changes in /var/log/audit/audit.log. The SSH daemon's use of the host keys at start-up is logged via journalctl -u sshd / /var/log/auth.log.
Remediation
Pavois's harden plan uses the file resource to set the owning group of /etc/ssh to ssh_keys (equivalent to chgrp ssh_keys /etc/ssh). Apply it with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | chgrp ssh_keys /etc/ssh/ssh_host_*_key 2>/dev/null || chgrp root /etc/ssh/ssh_host_*_key 2>/dev/null || true |
|---|---|
| name | chgrp-sshd-private-keys |
| not_if | [ -z "$(find /etc/ssh -name 'ssh_host_*_key' -type f ! -group root ! -group ssh_keys 2>/dev/null)" ] |
| resource | exec |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If the host private keys are group-readable by the wrong group, an attacker who reads them can impersonate the server. Setting the group to ssh_keys is the expected, supported configuration and does not disrupt SSH. Precautions: the ssh_keys group must exist (it ships with openssh-server on these distros); keep private keys at mode 0640 group ssh_keys and never widen them to world-readable, and avoid a session lockout by keeping an open SSH connection while changing key ownership and restarting sshd.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | high |
| CIS | 5.1.2, 5.1.4 | direct | per OS, see the benchmark table | 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.