Linux - System Preferences - Disable Remote Root Login (PermitRootLogin)

What the root SSH login disabler does

This Automox Worklet™ prevents direct SSH authentication to the root account on Linux endpoints. The Worklet edits /etc/ssh/sshd_config so the OpenSSH daemon rejects every root login attempt, regardless of whether the requestor presents a password or a public key. Local console root access and sudo or su escalation from a non-root account are both preserved, so the policy hardens remote access without locking administrators out of the host.

The remediation script first removes any existing PermitRootLogin directives with sed -i '/^\s*PermitRootLogin/d' /etc/ssh/sshd_config, then appends a single PermitRootLogin no line to the file. Before restarting the service, the Worklet runs /usr/sbin/sshd -t to validate the configuration syntax. The sshd service is restarted with systemctl restart sshd only when the syntax check passes, so a typo introduced elsewhere in the file cannot take SSH down on the endpoint.

The Worklet exits 0 when PermitRootLogin is already set to no, exits 1 with a message in stderr when remediation is required, and exits 1 if the SSH service fails to restart or the configuration test fails. The evaluation script is read-only, so a weekly recurring policy catches any future change that reintroduces direct root SSH access without imposing measurable load on compliant endpoints.

Why disable remote root SSH access

The root account exists on every Linux endpoint with the same name, which makes it the single most predictable target for SSH brute force and credential stuffing campaigns. An attacker only needs to guess the password or compromise a key to gain unrestricted privileges in one step. Disabling direct root login forces the attacker to first compromise a valid user account and then escalate, which doubles the prerequisites for a successful compromise and produces a complete audit trail of which user account initiated the session before becoming root. CIS Benchmarks call this out as control 5.2.8 (SSH PermitRootLogin disabled) and NIST 800-53 AC-6 (Least Privilege) treats the same restriction as a baseline hardening expectation. PCI-DSS, HIPAA, and SOC 2 audits routinely flag endpoints that allow PermitRootLogin yes.

This Worklet writes PermitRootLogin no to /etc/ssh/sshd_config on every Linux endpoint in scope, then reloads sshd so existing connections persist while new root-credentialed sessions are refused. The change is idempotent: hosts already aligned with the standard return without restarting the daemon, and any server where the directive has drifted back surfaces in the activity log on the next evaluation. CIS 5.2.8 and NIST 800-53 AC-6 controls produce deterministic fleet evidence rather than spot checks against a sample of servers.

How root SSH login hardening works

1. Evaluation phase: The Worklet first checks that /etc/ssh/sshd_config exists; endpoints without an SSH server installed exit 0 as not eligible. It then runs grep -E '^(\s*)?PermitRootLogin' /etc/ssh/sshd_config piped to awk '{print $2}' to extract the current value. If the value is not exactly no, or if the directive is missing or empty, the endpoint exits 1 and remediation is scheduled. Endpoints already at PermitRootLogin no exit 0 and stay compliant on the next policy run.

2. Remediation phase: The remediation script removes every line starting with optional whitespace and PermitRootLogin, then appends PermitRootLogin no to /etc/ssh/sshd_config. It re-reads the directive to confirm the new value, runs /usr/sbin/sshd -t to validate the file, and only then executes systemctl restart sshd. A failed syntax check or a failed service restart leaves PermitRootLogin no on disk but reports exit code 1 so the failure is visible in the Automox activity log instead of silently leaving SSH in a broken state.

Root SSH hardening requirements

• Linux endpoint with OpenSSH server installed and /etc/ssh/sshd_config present; endpoints without sshd_config are skipped

• Root or sudo privileges for the Automox agent to edit /etc/ssh/sshd_config and restart sshd (the default agent context already meets this)

• At least one non-root user account on the endpoint with sudo or wheel group membership so administrators can still elevate after the change

• systemd-based service manager (systemctl restart sshd); on SysV init endpoints, swap the restart command in remediation.sh to service sshd restart before scheduling

• An out-of-band recovery path (cloud provider serial console, IPMI, KVM, or physical access) in case an unrelated SSH configuration error surfaces during the next restart

• Coordinate with any Match blocks already in sshd_config; the Worklet sets the global PermitRootLogin directive and does not modify per-host or per-group Match overrides

Expected SSH state after root login is disabled

After a successful remediation, /etc/ssh/sshd_config contains a single PermitRootLogin no directive and the sshd service is running with the new configuration loaded. Any attempt to run ssh root@endpoint returns Permission denied, please try again at the prompt and an authentication failure entry in /var/log/auth.log (Debian, Ubuntu) or /var/log/secure (RHEL, CentOS, Rocky, Alma). Existing root-owned SSH sessions are not killed by the restart, so the policy does not interrupt active administrative work; the restriction takes effect for new connections only.

Validate the change by running grep -E '^PermitRootLogin' /etc/ssh/sshd_config on the endpoint, which should return exactly PermitRootLogin no, and sshd -T | grep -i permitrootlogin, which reflects the effective runtime value and is the authoritative answer when Match blocks are present. For audit evidence, capture both command outputs alongside the Automox policy run identifier; CIS Benchmark control 5.2.8 expects this artifact during a compliance assessment. Recurring evaluation runs report the endpoint as compliant on every subsequent policy cycle, and if an administrator or a configuration management tool re-enables PermitRootLogin, the next evaluation reads the modified directive and remediation rewrites sshd_config and restarts sshd within the same policy run.