sshd "PAM 2 more authentication failures" / "ignoring max retries"

Oct 18 03:51:11 web1 sshd-session[48211]: PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.7  user=root
Oct 18 03:52:44 web1 sshd-session[48230]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=198.51.100.22  user=deploy
Oct 18 03:52:44 web1 sshd-session[48230]: PAM service(sshd) ignoring max retries; 6 > 3

What it means

pam_unix keeps one small record per PAM handle to track failed authentications. The source comments its fields plainly: user is the “user that’s failed to be authenticated”, name is the “attempt from user with name”, uid the “uid of calling user”, euid the “euid of calling process” and count the “number of failures so far”.

Both of these lines come from the cleanup routine for that record, not from the moment a password is rejected. When the record is released or replaced — for sshd, as the authentication phase of that connection ends — and the count is greater than 1, pam_unix logs the summary. The logging block is guarded (if (!quiet && !err)), so a silent cleanup produces nothing at all.

Two details decide how you read the number:

• It prints count - 1. “5 more authentication failures” means pam_unix counted six. Add one.
• Singular at exactly two. The plural suffix is "" when the count is 2 and "s" otherwise, which is why you see both failure and failures in the same log.

The rest of the line is the format string filled in: logname= (the record’s name field), uid=/euid= (the sshd process calling PAM), tty=, ruser=, rhost= (the client address — the field that matters) and, only when the failed account name is non-empty, a literal user= plus the name. That literal carries its own leading space on top of the one already after rhost=%s, which is why real lines show two spaces before user=. Write your regexes accordingly.

The second line follows immediately, from the same block and the same PID, when the count exceeds UNIX_MAX_RETRIES — a constant defined in the module as 3. It prints the PAM service (sshd, or **unknown** if the item is unset), the count, and that limit: ignoring max retries; 6 > 3. The wording is literal. pam_unix logs and takes no action; the limit that actually cuts a connection off is sshd’s MaxAuthTries, documented default 6, which also notes that “Once the number of failures reaches half this value, additional failures are logged.”

Neither line can appear unless PAM password or keyboard-interactive authentication actually runs. A key-only server produces none of them.

Is it an attack?

Pattern	Reading
”1 more authentication failure” for a staff account from a known address, then Accepted	Someone mistyped and retried
One rhost=, many different user= values	Guessing across accounts — check the Invalid user and user-unknown lines on the same PIDs
One rhost=, same user=, repeating over hours	Targeted brute force against an account that exists
ignoring max retries on nearly every connection from a source	A client spending every attempt sshd allows — automated, not a human
user=root	Only possible where root password login is permitted; PermitRootLogin defaults to prohibit-password, which disables password and keyboard-interactive authentication for root
Any Accepted line from the same rhost=	Stop triaging and investigate the session

The count is bounded by what sshd permits per connection, so a high number tells you the limit is generous, not that the attacker is close to succeeding. The account name does the real work: a real service or staff account under repeated attempts outranks a thousand failures against invented names.

How to investigate

Pivot on rhost=, on user=, and on the PID that ties one connection together.

# Last 24 hours (Debian/Ubuntu unit is ssh; RHEL/Fedora use -u sshd)
sudo journalctl -u ssh --since "24 hours ago" \
  | grep -E "PAM [0-9]+ more authentication failures?;|ignoring max retries"

# Busiest sources (/var/log/auth.log; on RHEL/Fedora /var/log/secure)
sudo grep -oP 'PAM \d+ more authentication failures?;.*rhost=\K\S+' \
  /var/log/auth.log | sort | uniq -c | sort -rn | head -20

# Accounts those connections were working on
sudo grep -oP 'PAM \d+ more authentication failures?;.*user=\K\S+' \
  /var/log/auth.log | sort | uniq -c | sort -rn | head -20

# Connections that went past pam_unix's compiled-in limit of 3
sudo grep -c 'ignoring max retries' /var/log/auth.log

# One connection in full, by PID
sudo grep 'sshd-session\[48230\]' /var/log/auth.log

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

Check the names from the third command against /etc/passwd. For an exported auth.log the browser log analyzer groups these by source, and the SSH brute-force rule encodes the one-source-many-accounts shape as a detection.

How to stop it

• Turn off password paths and these lines disappear. PasswordAuthentication no (default yes) and, where PAM is enabled, KbdInteractiveAuthentication no (default yes) — the manual notes that “Because PAM keyboard-interactive authentication usually serves an equivalent role to password authentication, you should disable either PasswordAuthentication or KbdInteractiveAuthentication.” With neither running, pam_unix never counts a failure.
• Lower MaxAuthTries (default 6) to cap how high the count can climb on a single connection.
• Leave PerSourcePenalties enabled — penalties are on by default, and 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 once 15 seconds of penalty have accrued.
• 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.
• Keep LoginGraceTime (default 120 seconds) tight, and do not expose port 22 to the whole internet if a firewall rule, VPN or bastion will do.

sudo sshd -t && sudo systemctl reload ssh

Validate before reloading, and keep a working session open until you have tested a new one.