MaxAuthTries

What MaxAuthTries counts and its default

The sshd_config manual defines MaxAuthTries as the maximum number of authentication attempts permitted per connection, with a default of 6. It also says that once the number of failures reaches half this value, additional failures are logged. In the OpenSSH source, failed attempts are counted per connection: the initial "none" probe is not counted, and a partial success (one step of a multi-step AuthenticationMethods chain) is not counted as a failure.

When the count reaches the limit, sshd logs "maximum authentication attempts exceeded for" followed by the user, address and port, and disconnects the client with "Too many authentication failures". Ordinary failures are logged in the form "Failed password for invalid user NAME from ADDRESS port N ssh2", with "invalid user" appearing only when the account does not exist.

The counter belongs to the connection. It does not lock the account, and a client can simply open a new connection and start again.

A sensible setting and how to verify it

A value of 3 is a common hardening choice and appears in our SSH hardening guide. The default of 6 is not dangerous on a key-only server, so treat this as tightening rather than a fix. Add the line, check the file and read back the effective value:

# /etc/ssh/sshd_config
MaxAuthTries 3

sudo sshd -t
sudo sshd -T | grep -i '^maxauthtries '
sudo systemctl reload ssh     # sshd on some distributions

If you use Match blocks, MaxAuthTries is allowed inside them, so add -C user=deploy,addr=192.0.2.10,host=server to sshd -T to see the value for a specific connection, as the sshd(8) manual describes. On a test host with passwords still enabled you can enter wrong passwords for a made-up user and watch the log for the "maximum authentication attempts exceeded" line (on journald systems, sudo journalctl -u ssh; the unit is sshd on some distributions). Do not run this test against your production login.

Interactions and common mistakes

The classic surprise is a legitimate user who sees "Too many authentication failures" before a password prompt even appears. A client with an agent holding many keys can use up the attempts offering the wrong ones. The fix is on the client: name the key and stop offering the rest, with IdentitiesOnly yes and IdentityFile in ssh_config, which the ssh_config manual describes for agents that offer many identities.

• Mistyped passwords and mistyped verification codes count, so a very low value punishes real users on a two-factor setup.
• The limit is per connection. An attacker who reconnects gets a fresh count, so it does not replace rate limiting.
• As with other keywords, the first obtained value is used, so check included files and earlier lines.
• LoginGraceTime (default 120 seconds per the manual) is a separate limit on how long a connection may stay unauthenticated.

Where it fits in SSH hardening

MaxAuthTries narrows the window for guessing on each connection, which matters most while PasswordAuthentication is still enabled. Once passwords are off and only keys are accepted, the setting is a minor extra layer, because a bot cannot guess a private key in three tries or in six.

The real defence against repeated connections is outside sshd: fail2ban reads the "Failed" log lines and bans the source address, and a firewall can narrow who reaches the port at all, as covered in the fail2ban setup guide and the Linux firewall guide. Good logs make the lines above searchable, so see server monitoring and log analysis. For the full list of directives, read the sshd_config entry. Primary sources: the sshd_config manual and the OpenSSH auth2.c source.

Related terms: sshd_config, Brute-force attack, Fail2ban, Rate limiting, PasswordAuthentication.