Linux - Security - Enforce Number of SSH Login Attempts

What the SSH MaxAuthTries enforcer does

This Automox Worklet™ enforces a ceiling on the number of authentication attempts the SSH daemon accepts per inbound connection. When the limit is reached, sshd terminates the TCP session and the client must open a fresh connection to try again. The Worklet writes the chosen value to /etc/ssh/sshd_config, validates the file with sshd -t, and restarts the service so the policy takes effect on every new SSH handshake.

The default value is 4, the threshold called out in the CIS Distribution Independent Linux Benchmark MaxAuthTries control and mirrored in the Red Hat, Ubuntu, and Debian CIS profiles. The desired_maxauthtries variable is exposed as a policy input, so you can tighten the limit to 3 for hardened bastion hosts or lift it to 6 for engineering hosts where users carry several SSH keys on a single agent.

The Worklet only touches the MaxAuthTries directive. Other directives in /etc/ssh/sshd_config are left alone, so this policy composes safely with companion Worklets that disable password authentication, raise the protocol version, set ClientAliveInterval, or harden the cipher and KEX algorithm lists.

Why cap SSH authentication attempts

Brute-force and credential-stuffing tools against SSH succeed when they can try many passwords or keys per TCP session. The OpenSSH default of 6 attempts lets an attacker burn through six credential guesses for every connection opened, at very little cost. Capping MaxAuthTries at 4 forces the attacker to reconnect after every few failures, increasing TCP setup cost, generating more sshd authentication failure log lines for SIEM correlation, and giving rate-limit mechanisms like fail2ban, pam_faillock, and firewall throttles room to fire before the next attempt lands.

The CIS Distribution Independent Linux Benchmark MaxAuthTries control, along with NIST 800-53 IA-5 and PCI-DSS 8.3.x controls on authentication, expect this setting to be in place and auditable. Manual sshd_config edits are difficult to keep aligned across hundreds of servers, build images, and contractor workstations. A recurring Automox policy against your Linux server and workstation groups holds MaxAuthTries at the configured value on every targeted host, so newly imaged endpoints and ad-hoc cloud instances inherit the CIS-aligned SSH posture on the next agent check-in.

How SSH MaxAuthTries enforcement works

1. Evaluation phase: The Worklet uses systemctl status and systemctl is-active --quiet to confirm sshd is installed and running. If sshd is not present or not running, it exits 0 and the endpoint is treated as out of scope. When sshd is active, the script reads the effective value with sshd -T | grep -i maxauthtries | awk '{print $2}'. If that value is greater than desired_maxauthtries, the endpoint is flagged non-compliant and remediation is scheduled. An exact match exits 0 with no changes. Any other result – including an unparseable value – exits 1 so remediation can normalize the configuration.

2. Remediation phase: The remediation script uses sed -i to delete every existing MaxAuthTries or maxauthtries directive from /etc/ssh/sshd_config, then appends MaxAuthTries <desired_value> on a new line. It validates the resulting file with sshd -t before any restart, which prevents a typo or merge conflict from locking admins out of the host. On a clean validation, the script runs systemctl restart sshd and re-queries sshd -T to confirm the new value is live. Failures during the sed edit, sshd -t check, or systemctl restart write a descriptive message to stderr and exit non-zero so the Automox activity log captures the reason.

SSH MaxAuthTries policy requirements

• Linux endpoint with OpenSSH server installed and /etc/ssh/sshd_config present (RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu, Amazon Linux, SUSE)

• sshd service managed by systemd (the script uses systemctl is-active and systemctl restart)

• Root or sudo privileges for the Automox agent so it can write to /etc/ssh/sshd_config and restart the service (the default agent context already meets this)

• Optional: set the desired_maxauthtries input to override the default of 4. CIS recommends 4 or fewer; 3 is a common hardened-bastion choice

• If the host loads SSH overrides from /etc/ssh/sshd_config.d/*.conf, audit those drop-ins first – an override later in the include chain can re-raise MaxAuthTries even after this Worklet writes a lower value to the main file

• Schedule on a recurring policy so any image rebuild, configuration management push, or manual edit that resets sshd_config is caught on the next evaluation

Expected SSH behavior after enforcement

After a successful remediation run, /etc/ssh/sshd_config contains exactly one MaxAuthTries directive set to the desired value, and sshd has been restarted cleanly. Verify on the endpoint with sshd -T | grep -i maxauthtries, which prints the live runtime value rather than just the file contents. Connections that exceed the cap close with the standard OpenSSH message Received disconnect from <host> port 22:2: Too many authentication failures and a paired sshd[PID]: error: maximum authentication attempts exceeded for <user> from <ip> entry in /var/log/auth.log or the systemd journal.

Legitimate users who carry many SSH keys on a single ssh-agent may now hit the cap before the correct key is offered. Two client-side fixes resolve this without weakening the server policy: set IdentityFile and IdentitiesOnly yes in ~/.ssh/config for the affected host so the agent presents only the intended key, or pass -o IdentitiesOnly=yes -i <keyfile> on the ssh command line. For audit evidence, capture the output of sshd -T | grep -i maxauthtries together with the Automox policy run identifier; subsequent evaluations will mark the endpoint compliant without applying remediation again, because the on-disk value already matches the desired state.