unix_chkpwd "password check failed for user (root)": What It Means

Oct 18 03:51:11 web1 unix_chkpwd[48213]: password check failed for user (root)
Oct 18 03:51:14 web1 unix_chkpwd[48219]: password check failed for user (ubuntu)
Oct 18 04:06:58 web1 unix_chkpwd[48507]: password check failed for user (deploy)

What it means

This line is not written by sshd. It comes from unix_chkpwd, the helper binary that Linux-PAM’s pam_unix module uses to verify a password, which is why it appears in /var/log/auth.log with its own program tag and PID instead of sshd-session’s.

The sequence in the helper’s source is short. It calls helper_verify_password(), wipes the submitted password from memory, and if the result is anything other than PAM_SUCCESS it logs password check failed for user (%s) at LOG_NOTICE. The %s is the account name that was submitted, and it is the only variable in the message — no IP address, no source port, no PAM service name, no reason code.

Two details decide how much the line is worth:

• It does not prove the account exists. The message is written before the helper decides what to return. Only afterwards does the code separate the unknown-user case (PAM_USER_UNKNOWN, which it propagates as PAM_AUTHINFO_UNAVAIL) from a general failure. A name invented by a scanner produces the same text as a staff account with a mistyped password. The lines that do distinguish them are sshd’s Invalid user and pam_unix’s check pass; user unknown.
• A blank password under nullok is not logged. The code skips the message when the module permits empty passwords and the one supplied was blank — its comment reads “no need to log blank pass test”.

Where libaudit is compiled in, the helper also emits an AUDIT_USER_AUTH audit record, but only when its real uid is not 0.

Is it an attack?

On its own the line only says a password was offered for an account and did not check out. Read it together with the sshd lines carrying the same timestamp.

Pattern	Reading
One line for a real user, then that user logs in from a known address	A typo
Several lines naming the same account, seconds apart	Guessing against one account
Many different names in a short window — root, admin, ubuntu, user, test, deploy, postgres	A dictionary run against an exposed port
A name that should never authenticate by password — a service or key-only account	Worth chasing whatever the volume
Any of the above followed by an Accepted password line	Stop triaging and treat the account as compromised

Volume by itself is not a verdict: a host that accepts passwords from the internet produces these continuously. What changes the verdict is which names appear and what happened next.

How to investigate

# Helper failures in the journal, selected by syslog identifier
sudo journalctl -t unix_chkpwd --since "24 hours ago"

# Which account names were rejected (auth.log; on RHEL/Fedora use /var/log/secure)
sudo grep -oP 'password check failed for user \(\K[^)]+' /var/log/auth.log \
  | sort | uniq -c | sort -rn | head -20

# The sshd lines around one helper line — these carry the address and port
sudo grep -E 'password check failed for user|Failed (password|keyboard-interactive)|Invalid user' \
  /var/log/auth.log | grep 'Oct 18 03:51'

# Busiest source addresses, from sshd's own failure lines
sudo grep -oP 'Failed password for (?:invalid user )?\S+ from \K\S+' /var/log/auth.log \
  | sort | uniq -c | sort -rn | head -20

# Did anything succeed? Check every accepted login
sudo grep -E 'Accepted (password|publickey)' /var/log/auth.log | tail -50

Check the names from the second command against /etc/passwd: a real local account is a different problem from a scanner’s wordlist. 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 helper only runs when something asks PAM to verify a password, so remove the password paths and the lines stop.

• Turn off password authentication. PasswordAuthentication no (the default is yes), and where PAM is enabled also KbdInteractiveAuthentication no (also yes by default) — sshd_config(5) notes that “PAM keyboard-interactive authentication usually serves an equivalent role to password authentication”.
• Limit root. The default PermitRootLogin prohibit-password means “password and keyboard-interactive authentication are disabled for root”; no removes root logins entirely.
• Limit 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.
• Keep the connection limits tight. MaxAuthTries defaults to 6 attempts per connection and LoginGraceTime to 120 seconds.
• 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.
• Do not expose port 22 to the whole internet if a firewall rule, VPN or bastion can carry the traffic instead.

sudo sshd -t && sudo systemctl reload ssh   # RHEL/Fedora: systemctl reload sshd

Validate the configuration first and keep a working session open until a new one succeeds.