🚨 Linux Error: su: Authentication failure — Cause, Fix, and Troubleshooting Guide

Summary

su: Authentication failure means PAM rejected the credentials or policy check when switching users with su. The literal cause can be a wrong password, but in production it is frequently a locked account, an expired password, a PAM faillock lockout after failed attempts, or the target account having no password at all. Read the auth log to see which — the su output itself is deliberately vague.

Common Symptoms

• su - <user> or su - prints su: Authentication failure immediately after you enter the password.
• Repeated failures then lock you out entirely (faillock/pam_tally2 kicks in).
• su to a service account like postgres or www-data fails even as root on some systems.
• SSH key login works but interactive su/password login does not — pointing at password/PAM state, not the account existing.

Most Likely Causes of the ‘su: Authentication failure’ Error

su: Authentication failure is PAM returning PAM_AUTH_ERR. Ordered by how often it bites in production:

1. Wrong password — the obvious one, but rule the others out when it “should” be right.
2. Account is locked — passwd -l, an !/* prefix in /etc/shadow, or usermod -L.
3. Password/account expired — chage expiry passed, so PAM refuses even a correct password.
4. faillock / pam_tally2 lockout — too many failed attempts triggered a temporary deny.
5. Target account has no password set (! in shadow) — common for system/service accounts; you must su as root or set a password.
6. pam_wheel restricts su — the caller is not in the wheel/sudo group but PAM requires it.

Quick Triage

# Is the target account usable, locked, or passwordless?
sudo passwd -S <user>       # P=usable, L=locked, NP=no password
sudo chage -l <user>        # expiry dates
# Any active lockout?
sudo faillock --user <user>            # RHEL/Rocky 8+
sudo pam_tally2 --user <user>          # older RHEL / Debian
# What did PAM actually say?
sudo tail -n 20 /var/log/auth.log      # Ubuntu/Debian
sudo journalctl _COMM=su --since "-10 min"   # RHEL/Rocky

passwd -S returning L or NP, or a non-zero faillock count, gives you the real cause immediately.

Diagnostic Commands

# Account status: usable vs locked vs no-password
sudo passwd -S <user>

<user> L ... = locked; <user> NP ... = no password (can’t su into with a password); <user> P ... = a usable password is set.

# Expiry — an expired password causes auth failure with a correct password
sudo chage -l <user>

Look at Password expires and Account expires; a past date blocks login.

# Confirm the account exists and its login shell
getent passwd <user>

A shell of /usr/sbin/nologin or /bin/false makes su - <user> fail after auth — different message, but worth ruling out.

# Lockout counters
sudo faillock --user <user>          # RHEL/Rocky 8/9 (pam_faillock)
sudo pam_tally2 --user <user>        # RHEL 7 / older Debian (pam_tally2)

A count at or above the deny threshold means the user is temporarily locked regardless of correct password.

# The authoritative reason — read the auth trail
sudo tail -n 40 /var/log/auth.log                 # Debian/Ubuntu
sudo journalctl -t su -t su-l --since "-15 min"    # RHEL/Rocky
sudo journalctl _COMM=su --since "-15 min"

Look for pam_unix(su:auth): authentication failure, account expired, or pam_faillock ... Consecutive login failures.

# Is su gated by pam_wheel?
grep -E 'pam_wheel|pam_faillock|pam_tally' /etc/pam.d/su
groups <caller>       # is the caller in wheel/sudo?

Fix / Remediation

1. Confirm the password — as root you can bypass it (su from root never prompts), which isolates whether it is a credential or account problem:

   sudo su - <user>    # if this works, the issue is the password or a lockout, not the account

2. Unlock a locked account:

   sudo passwd -u <user>      # or: sudo usermod -U <user>
   sudo passwd -S <user>      # verify now shows P

3. Clear a faillock / pam_tally2 lockout:

   sudo faillock --user <user> --reset     # RHEL/Rocky 8+
   sudo pam_tally2 --user <user> --reset    # older systems

4. Fix expiry if the password/account expired:

   sudo chage -d $(date +%F) <user>    # reset last-change to today
   sudo chage -M 99999 <user>          # remove forced max age (if policy allows)
   sudo chage -E -1 <user>             # clear account expiry

5. Set a password for a passwordless (NP) account, or just su as root:

   Warning: Setting a password on a service account (e.g. postgres, www-data) may violate policy — prefer sudo -u <user> / sudo su - <user> from an authorized admin instead of enabling password login.

   sudo passwd <user>

6. If pam_wheel is enforcing, add the caller to the required group rather than removing the control:

   sudo usermod -aG wheel <caller>      # RHEL   (or 'sudo' on Debian/Ubuntu)

Validation

# Account is usable and not locked/expired
sudo passwd -S <user> | grep -q ' P ' && echo "usable"
sudo faillock --user <user> | tail -1
# The actual switch succeeds
su - <user> -c 'id'

A P status, a zeroed faillock count, and a working su - <user> -c 'id' confirm the fix.

Prevention

• Define a clear faillock policy (deny, unlock_time) in /etc/security/faillock.conf so lockouts auto-expire instead of requiring manual resets.
• Manage user accounts, passwords, and expiry through config management (Ansible user) so locked/expired state is intentional and visible.
• Monitor /var/log/auth.log / the journal for repeated authentication failure bursts — they indicate brute-force or a broken automation credential.
• Use sudo -u <user> for service accounts instead of giving them passwords; keep service accounts nologin.
• Document which accounts are intentionally NP/locked so on-call does not mistake them for breakage.

Related Errors

• Linux Error: passwd: Authentication token manipulation error
• Linux Error: sudo: unable to resolve host
• Linux Error: Permission denied
• Linux Error: Operation not permitted

Final Notes

su: Authentication failure is intentionally vague, so let PAM’s log speak: check passwd -S, chage -l, and faillock/pam_tally2 before assuming a typo. Locked accounts, expired passwords, and lockouts are the usual culprits, and each has a one-line fix once you have identified it. On Ubuntu read /var/log/auth.log; on RHEL/Rocky use journalctl.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.