🚨 PAM Error: 'pam_unix(sshd:auth): authentication failure' — Cause, Fix, and Troubleshooting Guide

What this error means

PAM’s pam_unix module rejected a password authentication attempt. The line is logged by the service that called PAM (here sshd) and records who tried, from where, and as which user. A steady trickle is normal internet background noise; a burst from one source, or repeated failures for a legitimate user, points at a real problem.

pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.7 user=deploy

The key fields are rhost= (source IP), user= (target account), and the service in pam_unix(sshd:auth). Whether this is an attack or a misconfiguration is decided by the pattern, not the single line.

Where it surfaces

• Repeated authentication failure lines in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL).
• A known-good user cannot log in despite the correct password.
• Many failures from a handful of IPs targeting root or common usernames.
• journalctl -u sshd shows Failed password paired with the PAM line.

Identity and permission causes

• Wrong password / brute force. Automated scanners spray credentials against sshd; each miss logs this line.
• Expired password. The account’s password aged out (chage), so even the correct one is rejected at auth time.
• Locked account. pam_faillock/pam_tally2 locked the user after too many failures, or the account is administratively locked.
• Clock/keytab or NSS mismatch. For networked accounts (LDAP/SSSD), a backend outage makes local pam_unix fall through to failure.
• PAM stack misconfiguration. A broken edit to /etc/pam.d/sshd or common-auth rejects valid credentials.

Tracing the failed authorization

# Recent PAM auth failures with source and target
sudo grep 'authentication failure' /var/log/auth.log | tail -20   # or /var/log/secure

# Rank attacking sources
sudo grep 'authentication failure' /var/log/auth.log \
  | grep -oE 'rhost=[0-9.]+' | sort | uniq -c | sort -rn | head

# Is the specific account expired or locked?
sudo chage -l deploy
sudo passwd -S deploy            # shows L (locked), P (usable), NP (no password)
sudo faillock --user deploy       # current failure count, if pam_faillock is used

A concentrated rhost count signals brute force; a single legitimate user failing points at expiry/lock or a backend outage.

Resolution

1. For brute force, let fail2ban ban repeat offenders and disable password auth in favor of keys:

sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl reload ssh
sudo systemctl enable --now fail2ban

2. For an expired password, reset aging or set a new password:

sudo chage -d "$(date +%Y-%m-%d)" deploy   # reset last-change date
sudo passwd deploy                          # or set a new password

3. For a locked account, clear the counter after verifying it is legitimate:

sudo faillock --user deploy --reset          # pam_faillock
sudo passwd -u deploy                         # unlock an administratively locked account

4. For a broken PAM stack, validate before you get locked out (keep a root session open):

sudo grep -R pam_unix /etc/pam.d/sshd /etc/pam.d/common-auth
# revert the bad edit; test in a second session before closing the first

Hardening access

• Keep a second privileged session open whenever editing PAM or sshd — a bad change can lock you out entirely.
• Disabling password auth is the single biggest win, but confirm your SSH keys work first.
• Do not confuse background-noise brute force with a targeted account problem; the rhost/user distribution tells them apart.
• Networked-auth failures (LDAP/SSSD) are often a backend outage, not a bad password — check the directory service before resetting anything.

Related identity errors

• Auditing PAM and Password Policy with AI
• SSH ‘no matching host key type’ Error Guide
• pam_faillock ‘Account Locked’ Error Guide