Linux - System Preferences - Disable Password Authentication for SSH

What the SSH password authentication disabler does

This Automox Worklet™ disables password-based authentication for the OpenSSH server on Linux endpoints. After remediation, the sshd daemon refuses interactive password logins, and users must present a private key that matches an entry in ~/.ssh/authorized_keys to open a session. The change applies to every account exposed by sshd, including root, sudo users, and service accounts.

The Worklet first confirms that /etc/ssh/sshd_config exists and re-reads the effective password setting with sshd -T. If the directive is already no, the Worklet exits without writing. Otherwise it strips every existing PasswordAuthentication directive from the file with a sed alternation that matches both the canonical and lowercase spellings, appends the canonical PasswordAuthentication no line, and runs /sbin/sshd -t to validate syntax before any service action.

When the validation passes, the Worklet calls systemctl restart sshd to reload the daemon. Active SSH sessions are preserved across the restart on every supported distribution, so the policy is safe to run during business hours. If sshd -t fails, the Worklet exits non-zero, writes the error to the Automox Activity Log, and leaves sshd running on its previous configuration.

Why disable SSH password logins

Internet-reachable SSH servers receive continuous credential-stuffing and dictionary attacks against accounts like root, ubuntu, admin, ec2-user, and oracle. Even a strong password policy is insufficient: leaked credentials from unrelated breaches feed into automated scanners within hours, and one reused password on one developer laptop is enough for an attacker to land a session. CIS Benchmark control 5.3.4 (Linux Server) and NIST 800-53 AC-17(2) and IA-2(11) both require cryptographic authentication for remote administrative access. PCI-DSS 8.3.1 reaches the same conclusion for any endpoint that stores or processes cardholder data.

Password authentication is rarely re-enabled by users; it is re-enabled by package upgrades that ship a fresh /etc/ssh/sshd_config, by golden images that predate the hardening baseline, and by ad-hoc admin edits that never propagate. This Worklet writes PasswordAuthentication no to /etc/ssh/sshd_config on every Linux endpoint in scope and reloads sshd so the next dictionary attack reaches a daemon that no longer accepts a credential. Subsequent evaluations confirm the directive on already-hardened hosts and surface any regression in the activity log.

How SSH password authentication enforcement works

1. Evaluation phase: The evaluation script checks for /etc/ssh/sshd_config and exits 0 with a skip message if the file is absent (the host is not running an OpenSSH server). When the file exists, the Worklet runs sshd -T to print the effective, post-include configuration and greps for the passwordauthentication line. If the value is no, the endpoint is already compliant and the script exits 0. Any other value, including unset or yes, exits 1 and schedules remediation.

2. Remediation phase: The remediation script repeats the file-existence and current-value checks, then runs sed -i '/^\s*\(PasswordAuthentication\|passwordauthentication\)/d' /etc/ssh/sshd_config to remove every existing directive whose key matches either spelling. It appends PasswordAuthentication no on a new line, validates the resulting file with /sbin/sshd -t, and restarts the daemon with systemctl restart sshd. The script exits 0 on a clean restart, exits 1 if systemctl fails, and exits 1 with a stderr message if the syntax check rejects the new configuration.

SSH password disable requirements

• Linux endpoint running OpenSSH with the daemon configuration at /etc/ssh/sshd_config (the OpenBSD default path used by RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu, SUSE, and Amazon Linux)

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

• systemd-managed sshd unit reachable via systemctl restart sshd (use a wrapper for sysvinit hosts or the ssh service name on older Debian releases)

• SSH public keys already deployed to every account that needs remote access, with permissions 600 on ~/.ssh/authorized_keys and 700 on ~/.ssh

• Out-of-band recovery path (console, serial, cloud-provider session manager, or IPMI) in case a key roll-out is incomplete

• No conflicting Match blocks in /etc/ssh/sshd_config that re-enable PasswordAuthentication for specific users, groups, or address ranges; sshd -T already accounts for these and will report the effective value

Expected SSH state after remediation

After a successful run, /etc/ssh/sshd_config contains the line PasswordAuthentication no with no conflicting directives above it. The sshd daemon is restarted and accepting connections, and any subsequent interactive password attempt is rejected with Permission denied (publickey). Sessions that authenticate with a key listed in authorized_keys continue to work without any client-side change. Re-running the Worklet reports the endpoint as compliant and takes no action, because the evaluation phase finds passwordauthentication no on the first sshd -T call.

Validate on a pilot endpoint by running sshd -T | grep -i passwordauthentication and confirming the output reads passwordauthentication no. Tail /var/log/auth.log on Debian and Ubuntu, or journalctl -u sshd on RHEL-family systems, and attempt a password login from a workstation that does not have a deployed key – the daemon should log Failed password for invalid user and close the connection. For audit evidence, capture the post-change sshd_config and the systemctl status sshd output and store them with the Automox policy run identifier. The hardened state survives reboots and package upgrades unless a maintainer ships a replacement sshd_config; if that happens, the next evaluation reads passwordauthentication yes from sshd -T and remediation rewrites the directive and restarts sshd within the same policy run.