← All rules
SOCLE-CLD-SSH-009// SSHmediumeffective runtime

Disable SSH root Login with a Password (Insecure)

Requires PermitRootLogin prohibit-password so root may only log in over SSH with a key, never with a password.

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.

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 24.04CIS 1.0.0Ubuntu 26.04

Why this rule matters

This is the weaker, compatibility-oriented alternative to fully disabling root SSH: prohibit-password still permits direct root login but only via public-key (or other non-interactive) authentication, blocking password-based logins. This removes root's password from the online brute-force surface while keeping key-based automation that legitimately needs root. Prefer PermitRootLogin no where operationally possible.

What Pavois checks

Pavois reads the effective value from sshd -T, after all Includes, /etc/ssh/sshd_config.d/ drop-ins and Match blocks. The distinction between no, prohibit-password and yes is only reliable from the resolved output; a read of /etc/ssh/sshd_config could be overridden by a later drop-in.

describe command('sshd -T') do
  its('stdout') { should match(/^permitrootlogin\s+(prohibit\-password|without\-password|no)$/i) }
end

How to verify it is applied

Run sshd -T | grep -i '^permitrootlogin'. Expected output is permitrootlogin prohibit-password.

Inspect & investigate

Root login attempts are logged in /var/log/secure or via journalctl -u sshd (RHEL family); a password attempt for root is rejected and shows as a failed authentication line.

Remediation

No automated remediation for this rule, apply it manually following the standard.

Impact & precautions

Before applying, ensure root has an authorized SSH key installed (/root/.ssh/authorized_keys) if any workflow needs root SSH, or that an admin account with sudo exists, otherwise you may cut off the only root path. Test a second SSH session before closing the current one. Note this still allows direct root login by key, so it is weaker than PermitRootLogin no; password-only root automation will break and must move to keys.

Sources & references