OpenSSH · Event maximum authentication attempts exceeded
SSH: maximum authentication attempts exceeded
The SSH server cut a connection off after too many authentication attempts. The surprise is how often this happens to legitimate users who typed nothing wrong: an SSH client offers every key it has, one at a time, and each offer counts as an attempt.
Also written as Too many authentication failuresssh max auth tries exceeded
- How oftenFires regularly
- Vendor calls itauth.err
- Logauth
What it means for you
On a personal computer
If you were trying to connect to your own machine and it refused you before you could type a password, this is probably why — your SSH program tried several saved keys first and used up the allowance. It is a limit, not a lockout, and reconnecting works.
For an analyst
The two populations are easy to separate and worth separating: attempts from your own address space, with a valid username, are key-offer exhaustion; attempts from the internet against root or common usernames are guessing. The client-side fix — IdentitiesOnly=yes with an explicit IdentityFile — is worth documenting for your users, because the alternative is people raising MaxAuthTries on the server, which weakens the limit for everyone to fix a client problem.
The fields that decide it
Everything else in the log line is context.
- The username
- Who was being authenticated. This is the strongest single discriminator between the two causes.
-
A real user on the systemAlmost always key-offer exhaustion from an SSH agent with many keys loaded. -
rootGuessing, in almost every case, unless you genuinely permit direct root login. -
admin, test, oracle, ubuntu, piAutomated guessing against common defaults. - Source address
- Where from. Internal and recognisable points at the key-offer problem; external and unfamiliar points at a scanner.
- MaxAuthTries
- Not in the message, but the setting that produced it. The default is 6, and each public key an agent offers consumes one — which is why a developer with several keys can be refused before a password prompt ever appears.
- Preceding lines
- What came immediately before. A run of 'Failed publickey' lines for one user means key exhaustion; a run of 'Failed password' means guessing.
Common questions
Why do I get 'Too many authentication failures' when I have not typed a wrong password?
Because your SSH client offered every key your agent holds before falling back to a password, and each offer counts against MaxAuthTries. With six keys loaded and a default limit of six, the connection is cut before you are ever prompted. Add 'IdentitiesOnly yes' along with the correct IdentityFile to that host's entry in ~/.ssh/config and the client will offer one key instead of all of them.
Should I raise MaxAuthTries to fix this?
Not for the key-offer case — that is a client problem and raising the server limit weakens it for everyone, including people guessing passwords. If anything, lowering it hardens the server, provided your users have their client configuration right. Raise it only where a specific legitimate workflow genuinely needs more attempts.
Does this event mean someone is trying to break in?
It depends entirely on the username and the source. A valid local username from an address you recognise is a client configuration issue. root or a generic name like admin from an unfamiliar address is automated guessing, which every internet-facing SSH server sees continuously. Check whether a successful login followed from the same address — that is the question that matters.
How do I stop the log filling with these from the internet?
Move SSH behind a VPN or restrict it by source address if you can, since that removes the traffic rather than the log lines. Failing that, key-only authentication with PasswordAuthentication disabled makes guessing pointless, and a rate-limiting tool such as fail2ban reduces the volume. Changing the port cuts noise from indiscriminate scanning but does nothing against anyone actually looking at you.
Read next
- Usually comes before Failed password: an SSH login was rejected The individual password failures that accumulate toward this limit.
- The equivalent of SSH: connection closed before authentication finished A connection that ended before authentication finished, which looks similar in the log and means something different.
- Read alongside Invalid user: an SSH login for an account that does not exist Attempts against usernames that do not exist, the clearest sign of automated guessing.
- Usually comes after Accepted password: an SSH login succeeded The successful login, which is the thing to check for after any run of failures.
- Read alongside pam_unix authentication failure: a login was rejected The PAM-level record of the same failures.
Vendor documentation
Last reviewed 6 September 2026