MaxTries

MaxTries is an sshd configuration setting that limits how many authentication attempts a client gets before the connection is closed. It is a practical control for slowing password guessing, but it must be tuned carefully because several checks can count as attempts. Too low a value can block legitimate users prematurely.

What MaxTries Actually Controls in sshd

MaxTries is a connection-level throttle, not an account lockout policy. It limits how many authentication attempts one SSH session may consume before sshd drops the connection, which makes password guessing slower and more expensive for an attacker. In practice, it sits inside the broader hardening posture described by CIS Benchmarks, where login behaviour is tuned to reduce brute-force exposure without breaking legitimate access.

Because sshd may count multiple checks as separate attempts, the effective user experience can differ from the raw number in the config. That is why MaxTries is best understood as a session budget for authentication progress, rather than a simple “password attempts” counter.

Why the Setting Needs Careful Tuning

The value is useful precisely because it raises the cost of online guessing, but the control is blunt. A value that is too permissive gives attackers more chances per connection, while a value that is too strict can end legitimate logins before a user finishes a normal authentication flow.

This matters most where SSH is exposed to untrusted networks or used by automation that may involve key-based authentication, keyboard-interactive prompts, or multi-step MFA flows. A seemingly small configuration change can therefore alter both resilience against guessing and the reliability of normal access.

For administrators looking for the surrounding control model, NIST SP 800-53 Rev 5 Security and Privacy Controls places this kind of tuning in the broader access-control and system-hardening discipline.

How MaxTries Interacts With Other SSH Protections

MaxTries is strongest when it is paired with controls that reduce guessability in the first place, such as public-key authentication, strong authentication policies, rate limiting, and network exposure reduction. On its own, it only shortens a single session’s runway; it does not stop repeated reconnection attempts from the same source.

The setting also interacts with the authentication design itself. If the server allows several authentication methods or if one user action generates several checks, the practical threshold can be reached sooner than expected. That is why operators should understand the authentication path before they choose a number.

Where SSH is part of a larger identity or access strategy, it is also useful to think about the surrounding assurance model in NIST SP 800-63 Digital Identity Guidelines, especially when stronger authenticators are used to reduce reliance on repeated password entry.

Operational Guidance for Choosing a Value

Common misunderstanding: MaxTries is sometimes treated as a universal anti-bruteforce fix. It is not. It is one line of defence that should be set in context, after confirming which authentication methods are enabled and how many prompts a legitimate user may see during a normal login.

Practitioner note: Choose a value that blocks unproductive guessing without penalising valid users. The right threshold depends on your authentication mix, jump-host design, and whether the environment is interactive, automated, or subject to stricter administrative access controls.

Practitioner takeaway: Review MaxTries alongside the full SSH authentication path, because the safest value is the one that preserves legitimate access while still making online guessing economically unattractive.