sshd "maximum authentication attempts exceeded": MaxAuthTries Reached

Oct 18 03:51:11 web1 sshd-session[48211]: error: maximum authentication attempts exceeded for invalid user admin from 203.0.113.7 port 54321 ssh2 [preauth]
Oct 18 03:51:11 web1 sshd-session[48211]: Disconnecting invalid user admin 203.0.113.7 port 54321: Too many authentication failures [preauth]
Oct 18 04:02:37 web1 sshd-session[48502]: error: maximum authentication attempts exceeded for deploy from 198.51.100.22 port 40118 ssh2 [preauth]
Oct 18 04:02:37 web1 sshd-session[48502]: Disconnecting authenticating user deploy 198.51.100.22 port 40118: Too many authentication failures [preauth]

What it means

sshd counts failed authentication attempts for each connection separately. In the authentication loop, a failed attempt increments that connection’s failure counter — the code makes one exception, allowing the client’s opening none probe “without failure penalty” on the first attempt. When the counter reaches the configured limit, sshd calls auth_maxtries_exceeded(), which produces both of these lines back to back:

1. error: maximum authentication attempts exceeded for %s%.100s from %.200s port %d ssh2 — the account, the client address and the client source port.
2. The disconnect itself: the function immediately tears the connection down with the reason Too many authentication failures, and the packet layer logs that as Disconnecting %s: %.100s, where the first %s is the connection identifier %.200s%s%s port %d — logging preamble, address, port.

The limit is MaxAuthTries, which sshd_config(5) describes as “the maximum number of authentication attempts permitted per connection”, adding that “once the number of failures reaches half this value, additional failures are logged” and that “the default is 6”. That second half is why you normally see a few Failed password lines on the same PID before this pair.

Three details decide how you read the pair:

• The account name. On the error line the name is prefixed with invalid user when sshd could not look up a usable account record, and printed bare when it could. The disconnect line encodes the same distinction in its preamble — invalid user admin versus authenticating user deploy — because sshd sets that preamble when it handles the first authentication request on the connection.
• The address and source port. The port identifies the single TCP connection, which is how you tie these two lines to the Failed password or key-offer lines that preceded them under the same PID.
• The [preauth] tag. sshd’s monitor appends it to messages relayed from the pre-authentication process, so a tagged pair is proof the connection ended before any session existed.

Is it an attack?

Usually yes on an internet-facing host, but the shape matters.

Pattern	Reading
invalid user plus a different guessed name on every connection from one source	Name guessing and brute force — same story as Invalid user lines
One real account, many connections from one source, each ending in this pair	Targeted brute force against an account that exists
One source, a handful of real accounts, a few attempts each	Spraying spread across connections to stay under lockout-style controls
A known workstation, a real account, no password failures before it	A client offering more public keys than the limit allows
Any source that later appears on an Accepted line	Stop triaging and investigate the session

The pair never tells you a password was correct; for that you need the Failed password and PAM lines on the same PID, or the PAM: more authentication failures summary.

How to investigate

Pivot on the source address, then on the PID.

# Last 24 hours (Debian/Ubuntu unit is ssh; on RHEL/Fedora use -u sshd)
sudo journalctl -u ssh --since "24 hours ago" \
  | grep -E "maximum authentication attempts exceeded|Too many authentication failures"

# Busiest sources (/var/log/auth.log; on RHEL/Fedora /var/log/secure)
sudo grep -oP 'maximum authentication attempts exceeded for (?:invalid user )?\S+ from \K\S+' \
  /var/log/auth.log | sort | uniq -c | sort -rn | head -20

# Which account names clients burned their attempts on
sudo grep -oP 'maximum authentication attempts exceeded for \K(?:invalid user )?\S+' \
  /var/log/auth.log | sort | uniq -c | sort -rn | head -20

# The whole connection, by PID
sudo grep 'sshd-session\[48502\]' /var/log/auth.log

# Did any of those sources actually get in?
sudo grep -E "Accepted (password|publickey)" /var/log/auth.log | tail -50

Check every bare (non-invalid) name against /etc/passwd: a real service or staff account being worked on is a different conversation from a thousand throwaway names. For an exported auth.log, the browser log analyzer groups the lines by source, and the SSH brute-force rule encodes the one-source-many-names pattern as a detection.

How to stop it

• Take passwords out of the equation. PasswordAuthentication no (it defaults to yes) and, where PAM is enabled, KbdInteractiveAuthentication no — the manual notes PAM keyboard-interactive authentication usually serves an equivalent role to password authentication. After that, guessed passwords cannot consume attempts at all.
• Leave PerSourcePenalties enabled. Penalties are on by default; a client that disconnects after one or more unsuccessful authentication attempts is refused for 5 seconds by default, accumulating to a maximum of 10 minutes, with a 15-second minimum before enforcement begins.
• Restrict who may log in with AllowUsers — by default login is allowed for all users, and patterns may take the USER@HOST form with CIDR host criteria. PermitRootLogin defaults to prohibit-password, which disables password and keyboard-interactive authentication for root.
• Keep LoginGraceTime tight (default 120 seconds) so slow guessing connections are cut sooner.
• Tune MaxAuthTries with care. Lowering it shortens each connection but not the campaign, and setting it below the number of keys a legitimate agent offers will lock out your own users; those users can limit the keys offered with ssh -o IdentitiesOnly=yes -i <key>.
• Do not expose port 22 to the whole internet. A firewall rule, VPN or bastion removes most of these lines outright.

sudo sshd -t && sudo systemctl reload ssh

Validate before reloading, and keep an existing session open until a new one works.