SSH Disable PermitEmptyPasswords

What the SSH empty password blocker does

This Automox Worklet™ blocks SSH authentication attempts that use empty passwords by setting PermitEmptyPasswords to no in /etc/ssh/sshd_config on every Linux endpoint in scope. The remediation script searches the SSH daemon configuration for any active (uncommented) PermitEmptyPasswords line and rewrites it in place. If no such line exists, the Worklet appends the directive at the end of the file so the setting is explicit rather than inherited from compiled-in defaults.

The script uses grep and sed against the canonical sshd configuration path, then offers an optional sshd restart line you can uncomment to apply the change without waiting for the next service reload. The Worklet is safe to run repeatedly: if the setting is already present and correct, sed rewrites the line to the same value and the script exits cleanly. That makes the policy suitable for both a one-time hardening sweep and a recurring drift check.

Behavior is identical across Debian, Ubuntu, RHEL, CentOS, Rocky, Alma, Fedora, SUSE, and Amazon Linux because the directive name and configuration path are part of the OpenSSH upstream specification rather than a distribution-specific patch. The Worklet does not modify Match blocks, drop-in files under /etc/ssh/sshd_config.d/, or any cipher and key-exchange settings; it touches only the global PermitEmptyPasswords directive.

Why block SSH empty password authentication

An SSH server that accepts empty passwords is one of the highest-severity findings a Linux endpoint can carry. Any local account with a blank entry in /etc/shadow becomes a network-reachable shell on port 22, and automated scanning tools can identify and exploit the condition without credentials. CIS Benchmark control 5.2.9 for SSH PermitEmptyPasswords, the RHEL STIG control for sshd PermitEmptyPasswords, NIST 800-53 IA-5, and PCI-DSS 8.2.3 all require the directive to be explicitly set to no, and security scanners flag the default-or-missing state as a critical control gap.

PermitEmptyPasswords drift is concentrated on the hosts that nobody routinely SSHes into: build-server snapshots cloned from an older AMI, container hosts spun up from a baked-in golden image, dev workstations a former contractor configured by hand, jump boxes inherited during an acquisition. Scheduling this Worklet on a recurring policy reasserts PermitEmptyPasswords no after every package upgrade or configuration management run that touches sshd_config, and produces a per-endpoint exit code that satisfies CIS 5.2.9 evidence requests on the same cadence.

How SSH empty password blocking works

1. Evaluation phase: The evaluation script always exits non-zero so the Automox agent schedules remediation. The Worklet treats PermitEmptyPasswords no as a state to be reasserted on every run rather than a one-time install, which keeps the configuration aligned even if a package upgrade or admin edit replaces /etc/ssh/sshd_config between cycles.

2. Remediation phase: The remediation script runs grep against /etc/ssh/sshd_config for any line matching PermitEmptyPasswords, whether commented or active. If a line is found, sed rewrites it to PermitEmptyPasswords no. If no line is found, the script appends PermitEmptyPasswords no to the end of the file. An optional final command, service sshd restart, is left commented in the script; uncomment it to apply the change immediately on every endpoint the policy touches.

SSH empty password policy requirements

• Linux endpoint with the OpenSSH server package (openssh-server, openssh) installed and /etc/ssh/sshd_config present

• Root or sudo privileges for the Automox agent (the default agent context already meets this)

• The service command available on the endpoint if you uncomment the optional sshd restart line; systemd hosts may substitute systemctl restart sshd

• No conflicting drop-in file under /etc/ssh/sshd_config.d/ that re-enables PermitEmptyPasswords after the main file is hardened

• Suitable for servers, container hosts, build agents, and developer workstations; no kernel or hardware constraints

Expected SSH state after enforcement

After remediation, /etc/ssh/sshd_config contains an explicit PermitEmptyPasswords no line. The sshd daemon reads this directive on the next reload or restart and rejects any authentication attempt that submits an empty password, regardless of whether the target account has a blank shadow entry or no password set at all. Existing SSH sessions remain connected; the enforcement applies to new authentication attempts only.

Confirm the daemon is reading the new value with sshd -T | grep permitemptypasswords, which prints the effective runtime configuration rather than just the on-disk file. The output should read permitemptypasswords no. Use sshd -t to validate the configuration syntax before any restart; a clean syntax check prevents a typo from leaving SSH unavailable on a remote endpoint. Inspect /etc/ssh/sshd_config directly with grep -i permitemptypasswords /etc/ssh/sshd_config to confirm the on-disk state, and review /var/log/auth.log (Debian, Ubuntu) or /var/log/secure (RHEL family) for the SSH daemon's startup banner after the restart.

For audit evidence, pair this Worklet with a recurring evaluation policy and export the activity log entries that report exit code 0 against the configured endpoints. The same evidence trail satisfies CIS Benchmark 5.2.9, the RHEL STIG control for sshd PermitEmptyPasswords, and the SSH-hardening line items in NIST 800-53 IA-5 and PCI-DSS 8.2.3. If a future package upgrade or admin edit reverts the directive, the next policy run reasserts PermitEmptyPasswords no without manual intervention.