sshd "pam_unix(sshd:auth): authentication failure": What It Means

Oct 18 03:51:11 web1 sshd-session[48211]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.7  user=root
Oct 18 03:51:14 web1 sshd-session[48211]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.7  user=root
Oct 18 03:52:40 web1 sshd-session[48244]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=198.51.100.22  user=deploy
Oct 18 03:53:05 web1 sshd-session[48260]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=198.51.100.22 

What it means

This line is written by pam_unix, the PAM module that checks passwords against the local account database, during the authentication phase of the sshd PAM service. The prefix is assembled by PAM’s logging helper from three parts — the module name, the service name and the phase — giving pam_unix(sshd:auth). Everything after it comes from one format string in pam_unix, so the field list is always the same:

• logname= and ruser= — taken from the module’s failure record and from the PAM_RUSER item. Under sshd there is no invoking local user, so both are normally empty; the code substitutes an empty string when the item is unset.
• uid= / euid= — the credentials recorded for the process that called PAM, normally 0 because sshd’s privileged process runs as root.
• tty= — the PAM_TTY item, which sshd sets to ssh.
• rhost= — the PAM_RHOST item: the client’s IP address. This is the field you pivot on.
• user=<name> — appended only when the module has an account name for the attempt. Note the double space before it: the format puts a space after rhost=%s, and the appended text begins with another.

The line says one thing: the credentials presented for that attempt were not accepted. It does not say the connection ended, and it does not say whether the account exists — for a name with no local record you normally get this line without user=, alongside pam_unix’s separate “check pass; user unknown” message.

Is it an attack?

On a host with port 22 open to the internet this is one of the highest-volume authentication messages there is, and most of it is untargeted password guessing. The shape around the line is what matters.

Pattern	Reading
One user= name, two or three lines, then Accepted from the same address	Someone mistyped their password
user=root repeatedly from one address	Generic bot — check PermitRootLogin, whose default is prohibit-password
Many different user= names from one rhost=	Name and credential guessing — see Invalid user
One real service or staff account, many sources, low rate each	Spraying against a known account; treat as targeted
Lines with no user= only	Guesses at names that do not exist locally
Any of the above followed by an Accepted line from the same address	Stop triaging and investigate the session

The SSH brute-force rule encodes the one-source-many-accounts shape as a detection.

How to investigate

Group by source, then by account, then read one connection end to end by PID.

# Last 24 hours (Debian/Ubuntu unit is ssh; on RHEL/Fedora use -u sshd)
sudo journalctl -u ssh --since "24 hours ago" | grep 'pam_unix(sshd:auth): authentication failure'

# Busiest source addresses (/var/log/auth.log; on RHEL/Fedora /var/log/secure)
sudo grep -oP 'pam_unix\(sshd:auth\): authentication failure;.*rhost=\K\S+' \
  /var/log/auth.log | sort | uniq -c | sort -rn | head -20

# Which accounts were named
sudo grep -oP 'pam_unix\(sshd:auth\): authentication failure;.*user=\K\S+' \
  /var/log/auth.log | sort | uniq -c | sort -rn | head -20

# Distinct accounts per source: many accounts from one address is spraying
sudo grep 'pam_unix(sshd:auth): authentication failure' /var/log/auth.log |
  sed -n 's/.*rhost=\([^ ]*\).*user=\([^ ]*\).*/\1 \2/p' | sort -u |
  awk '{c[$1]++} END {for (i in c) print c[i], i}' | sort -rn | head -20

# Everything one connection did, by PID
sudo grep 'sshd-session\[48244\]' /var/log/auth.log

# Did any source that produced failures get in?
sudo grep -E 'Accepted (password|publickey|keyboard-interactive)' /var/log/auth.log | tail -50

Check every name that appears in user= against /etc/passwd: a live service account being hammered is a different problem from a bot cycling through admin, test and oracle. The companion Failed password lines give you sshd’s view of the same attempts, and Connection closed usually ends the connection. For an exported auth.log, the browser log analyzer groups these lines by source address.

How to stop it

• Take passwords out of the exchange. PasswordAuthentication no (the default is yes) and, because PAM keyboard-interactive usually serves an equivalent role, KbdInteractiveAuthentication no as well. With key-only authentication, pam_unix has nothing to reject.
• Keep root out of reach. PermitRootLogin defaults to prohibit-password, which disables password and keyboard-interactive authentication for root.
• Limit who may authenticate at all with AllowUsers; by default login is allowed for all users, and patterns may take the USER@HOST form with CIDR host criteria.
• Cut off the retries. MaxAuthTries defaults to 6 attempts per connection, and LoginGraceTime disconnects after 120 seconds without a successful login.
• 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 up to a maximum of 10 minutes once the 15-second minimum has accrued.
• Restrict exposure. Firewall port 22 to known networks or front it with a VPN or bastion; nothing reduces the volume more.

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractive|usepam|permitrootlogin|maxauthtries'
sudo sshd -t && sudo systemctl reload ssh

Check the effective settings, validate the configuration, and keep an existing session open until a new one works.