## 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
```text
"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