sshd "pam_unix(sshd:auth): check pass; user unknown": What It Means

Oct 18 03:51:11 web1 sshd-session[48211]: pam_unix(sshd:auth): check pass; user unknown
Oct 18 03:51:14 web1 sshd-session[48214]: pam_unix(sshd:auth): check pass; user unknown
Oct 18 03:51:19 web1 sshd-session[48221]: pam_unix(sshd:auth): check pass; user unknown

What it means

The prefix tells you who wrote the line: the pam_unix module, running under the PAM service sshd, in the auth stack. The message itself comes from pam_unix’s password-checking path.

That code first tries to obtain a usable password record for the name the client supplied. If it gets one, it hands the comparison to the external helper binary — the path that produces an ordinary authentication failure when the password is simply wrong. If it does not, it takes the branch the source marks “user’s record unavailable”: there is nothing to compare the password against, so the check fails immediately and this line is logged.

Two details of the logging are worth knowing:

• The name is removed on purpose. By default pam_unix clears the name and logs the bare check pass; user unknown. With the module’s audit option it logs check pass; user (%s) unknown instead. The source explains why the default is the quiet one: “this might be a typo and the user has given a password instead of a username. Careful with this.”
• Silence is also possible. The bare line is written when debug logging is on, or when the password structure came back NULL — the “no such account at all” case. If a record exists but no usable hash does, and debug is off, pam_unix logs nothing and moves on, because, in the words of the comment, “don’t log failure as another pam module can succeed”.

So in practice this line is your “the account does not exist here” signal from the PAM side, the counterpart to sshd’s own Invalid user line.

Is it an attack?

Almost always it is automated guessing, but the shape around it decides.

Pattern	Reading
One or two lines around a user’s successful login	A typo, or a password pasted into the login prompt
One line per connection, many connections, each PID also carrying Invalid user <name> from <ip>	Internet-wide SSH scanning working through a name list
Several lines on one PID	One client retrying several passwords for a name you do not have (MaxAuthTries, default 6, caps the attempts per connection)
Lines interleaved with Failed password and pam_unix(sshd:auth): authentication failure for names you do have	The same source is also hitting real accounts — raise priority
Any Accepted line from a source that produced these	Stop triaging and investigate the session

The useful property of this message is that it separates misses from near-misses. Guesses like ftpuser, solana, test or user1 land here because no such account exists; guesses at names that exist on the host — root always, ubuntu or postgres where an image or package created them — never reach this branch, because a record was found and the password was actually checked.

How to investigate

The line carries no address, so every pivot goes through the PID.

# Debian/Ubuntu: unit is ssh. RHEL/Fedora: journalctl -u sshd, log /var/log/secure
sudo journalctl -u ssh --since "24 hours ago" | grep 'check pass; user unknown'

# How many, per day, in the file log
sudo grep -c 'pam_unix(sshd:auth): check pass; user unknown' /var/log/auth.log

# The whole story of the connections that produced them: PID -> all its lines
for pid in $(sudo grep -oP 'sshd-session\[\K[0-9]+(?=\]: pam_unix\(sshd:auth\): check pass; user unknown)' \
             /var/log/auth.log | sort -u | tail -20); do
  echo "--- pid $pid"; sudo grep "sshd-session\[$pid\]" /var/log/auth.log
done

# Names and sources, taken from sshd's own lines rather than from PAM
sudo grep -oP 'Invalid user \K\S+ from \S+' /var/log/auth.log | sort | uniq -c | sort -rn | head -20

# The only question that changes severity
sudo grep -E 'Accepted (publickey|password)' /var/log/auth.log | tail -50

If the attempted names turn out to be real accounts, you are reading the wrong message — those attempts log an authentication failure instead. For an exported auth.log, the browser log analyzer groups the surrounding sshd lines by source, and the SSH brute-force rule encodes the one-source-many-names pattern as a detection.

How to stop it

The line is only ever written when the PAM auth stack runs, so the fix is to stop running it for strangers.

• Turn off password-based logins. PasswordAuthentication no (the default is yes) and, with PAM enabled, KbdInteractiveAuthentication no (also yes by default) — the manual notes PAM keyboard-interactive authentication usually serves an equivalent role to password authentication, and recommends disabling one of the two. With neither enabled there is no password for pam_unix to check, and these lines stop.
• Keep port 22 off the open internet where you can: firewall it to known ranges, or front it with a VPN or bastion. Nothing reduces the volume more.
• 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.
• Tighten the per-connection limits: MaxAuthTries (default 6) and LoginGraceTime (default 120 seconds).
• Restrict who may log in at all 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 already disables password and keyboard-interactive authentication for root.

sudo sshd -t && sudo systemctl reload ssh

Validate the configuration before reloading, and keep a working session open until a new one succeeds.