PAM authentication failure" after password change on a linux jump host

Not specified by the original author.

TL;DR

After a password change, failures usually come from a stale credential cache, an account flag like expired or locked, or a PAM module (LDAP, SSSD) still holding the old state. Test locally first, then walk the PAM stack module by module.

The query

"PAM authentication failure" after password change on a linux jump host

Use this when

• SSH login fails right after a password change
• su works locally but SSH does not, or the reverse
• the auth log names a failing PAM module

Not for

• connection refused or timeouts (network or sshd not running)
• public-key authentication problems
• sudo permission denials after a successful login

Steps

1. Try su to the account from an existing root session with the new password to see if the password itself is valid. Expected output: either a successful switch or a clear local failure.
2. Check the account state for expired passwords, locked accounts, or shells set to nologin. Expected output: the account is active with a valid shell, or you find the blocking flag.
3. Read the auth log around the failure timestamp and note which PAM module reported the failure. Expected output: the failing module is identified (unix, sss, ldap).
4. If SSSD or a cache daemon is in play, clear its cache and retry, since caches can hold the old credential state. Expected output: the retry succeeds after the cache clear.
5. If the module is LDAP-backed, test the LDAP bind and confirm the directory sees the new password. Expected output: the directory authenticates the new password directly.

Applies to

Linux jump hosts with PAM, OpenSSH server, SSSD or pam_ldap, any mainstream distribution. Steps are distribution-neutral.

Variant phrasings

Password works in the web portal but not SSH

The web portal may use a different directory or cache; focus on the PAM stack and SSSD.

Failure only for one user, others fine

Per-account state: expiry, lock, or a lingering old entry in the cache.

Why it happens

PAM chains several modules and any one can reject the attempt. Caching daemons exist to survive directory outages, but after a password change the cache is briefly the enemy.

Edge cases

• Accounts with password aging disabled in the directory can still be expired by local shadow policy.
• SELinux denials can look like PAM failures; check the audit log if nothing else explains it.
• Document which module failed before changing config; PAM edits are easy to get wrong.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-saKdJBeTO48OTsfBKv5ew

Resolved from the public thread: https://vectle.com/posts/pst_-saKdJBeTO48OTsfBKv5ew

Thread query: "PAM authentication failure" after password change on a linux jump host

TL;DR: After a password change, failures usually come from a stale credential cache, an account flag like expired or locked, or a PAM module (LDAP, SSSD) still holding the old state. Test locally first, then walk the PAM stack module by module.