Enable SSH MaxAuthTries

What the SSH MaxAuthTries hardening Worklet does

This Automox Worklet™ writes the MaxAuthTries directive into /etc/ssh/sshd_config so that the OpenSSH server disconnects any client that fails to authenticate within four attempts on a single connection. The default OpenSSH ceiling is six attempts. Reducing it to four is the value called out by the CIS Linux Benchmark and accepted by every common SSH client, including OpenSSH, PuTTY, MobaXterm, and the macOS Terminal.

The remediation script first confirms that sshd is running, then uses a regex-based grep to locate any existing MaxAuthTries line. If one is present, sed rewrites the value in place while preserving leading whitespace and any trailing comment. If the directive is missing, the script appends MaxAuthTries 4 to the end of the file. The Worklet ships with the service sshd restart line commented out, so the new setting takes effect on the next sshd restart or system reboot. Uncomment that line in the remediation script when you want the change applied immediately on a fleet that can tolerate a brief sshd reload.

Because sshd reads sshd_config only at startup, the in-memory configuration of an existing daemon is unaffected until the service is restarted. Active SSH sessions continue under the previous limit. New sessions opened after the restart immediately honor MaxAuthTries 4.

Why cap SSH authentication attempts at four

SSH brute-force activity is constant background noise on any internet-reachable Linux host. Automated scanners cycle through username and password lists, and OpenSSH's default of six attempts per connection lets an attacker burn down a small dictionary on each TCP session before having to reconnect. Capping MaxAuthTries at four cuts the per-session attempt budget by a third, forces a new TCP handshake for every additional batch of guesses, and produces a tighter rhythm of sshd Failed password log lines that fail2ban, CrowdSec, and SIEM correlation rules can latch onto. The control maps to CIS Linux Benchmark 5.2.7, which requires SSH MaxAuthTries to be set to 4 or less, and supports NIST 800-53 AC-7 account-lockout requirements as well as PCI-DSS 8.3.4.

SSH brute-force exposure tends to hide on the endpoints the security team did not catalog: freshly imaged Ubuntu workstations, one-off RHEL build servers, and contractor jump boxes that never make it onto the bastion-hardening checklist. An Automox policy applied to your Linux server and workstation groups enforces the same MaxAuthTries 4 baseline on every targeted host, so a newly enrolled endpoint inherits the CIS control on the next agent check-in rather than waiting for an admin to open an SSH session per host.

How MaxAuthTries enforcement works

1. Evaluation phase: The evaluation script exits 1 unconditionally, which schedules remediation on every policy run. Treat this Worklet as a run-once-then-rerun-to-reaffirm hardening action; the idempotent remediation makes repeated runs safe and effectively turns the policy into continuous enforcement of the four-attempt ceiling.

2. Remediation phase: The script reads the tries variable (default 4), checks that sshd is running with service sshd status, then runs grep -q -E against /etc/ssh/sshd_config to detect an existing MaxAuthTries entry. If present, sed -ri rewrites the value while preserving indentation and trailing comments; if absent, the script appends MaxAuthTries 4 to the end of the file. The service sshd restart line is commented by default. Uncomment it to reload sshd immediately, or rely on the next scheduled reboot or systemctl restart sshd to pick up the change.

SSH hardening requirements

• Linux endpoint running OpenSSH server (sshd) with /etc/ssh/sshd_config present

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

• sshd service active and reachable via the service sshd status wrapper, which works on both SysV init and systemd hosts

• To change the cap, edit the tries=4 variable at the top of remediation.sh before saving the policy

• To apply the change without waiting for a reboot, uncomment the service sshd restart line in remediation.sh

• Run sshd -t after remediation in a maintenance window to validate the rewritten sshd_config before relying on a restart

Expected SSH behavior after enforcement

After remediation runs and sshd is restarted, any SSH client that fails to authenticate four times in a row on a single connection is disconnected. Subsequent attempts require a fresh TCP handshake, which is exactly the friction the CIS control is meant to introduce. Verify the live configuration on the endpoint with sshd -T | grep maxauthtries; the command should print maxauthtries 4. Confirm the on-disk value with grep -E '^\s*MaxAuthTries' /etc/ssh/sshd_config, then run sshd -t to validate the config file parses cleanly before relying on the next sshd restart.

End users who mistype their password a few times will hit the cap and be dropped back to a prompt to reconnect. That is expected behavior, not a Worklet failure. Sessions authenticated by SSH key are unaffected in practice because key-based authentication succeeds on the first attempt. Pair this Worklet with fail2ban, CrowdSec, or an equivalent log-driven blocker for defense in depth: MaxAuthTries 4 slows the attack on a single connection, and the log-driven blocker bans the source IP after a handful of failed connections.