🚨 Security Error Guide: 'pam_faillock: Account locked due to failed logins'

Exact Error Message

After enabling lockout hardening with pam_faillock, a legitimate user is suddenly refused at login, and the auth journal records:

pam_faillock(sshd:auth): Consecutive login failures for user deploy account temporarily locked
pam_faillock(sshd:account): Account locked due to 5 failed logins

The user sees a generic failure at the prompt:

Permission denied, please try again.
Account locked due to failed logins

What the Error Means

pam_faillock is the PAM module that tracks consecutive failed authentication attempts and locks an account once a threshold (deny=) is reached, for a cooldown period (unlock_time=). The message means the per-user failure counter has hit or exceeded the configured limit, so PAM’s account phase now rejects the user even if they type the correct password.

This is an operational lockout, not a breach. Engineers hit it routinely after enabling lockout policy: a stale cached SSH key, a misconfigured automation job, or a monitoring probe hammers the login with bad credentials and trips the counter for a real user. The fix is to confirm the source of the failures, reset the counter, and tune the policy so legitimate traffic does not lock accounts.

Common Causes

• Stale or wrong credentials in automation. A CI job, backup agent, or cron task authenticates with an outdated password/key and burns through the deny= budget.
• Cached old SSH key still offered first. The client offers a revoked key, each rejection counting as a failure before the correct key is tried.
• Aggressive deny= threshold. A hardening baseline set deny=3 with a long unlock_time, so a couple of typos lock a user out for a long window.
• Shared service account. Multiple jobs use one account; one job’s bad credential locks the account for all of them.
• Counter never resets on success. Without even_deny_root understanding or a missing authsucc line, failures accumulate across sessions and eventually trip.
• Clock skew or NFS-mounted tally dir. The faillock tally directory is on shared storage and counters behave inconsistently across hosts.

How to Reproduce the Error

On a disposable test host with faillock configured (deny=3), deliberately fail logins for a test user:

for i in 1 2 3; do ssh -o PreferredAuthentications=password testuser@localhost true; done

After the third failure, even a correct attempt is rejected, and faillock shows the tally:

testuser:
When                Type  Source                                           Valid
2026-06-27 10:01:11 RHOST 10.0.0.5                                          V
2026-06-27 10:01:14 RHOST 10.0.0.5                                          V
2026-06-27 10:01:17 RHOST 10.0.0.5                                          V

Diagnostic Commands

These read-only commands identify who is locked, why, and from where.

# Show the current failure tally for a user (read-only)
faillock --user deploy

# Inspect the faillock policy in effect
grep -R faillock /etc/pam.d/ /etc/security/faillock.conf 2>/dev/null

# Where are the failures coming from? Read the auth journal
sudo journalctl -u sshd --since '1 hour ago' | grep -iE 'failed|faillock|invalid'

# Audit authentication failures via the audit log
sudo ausearch -m USER_AUTH,USER_LOGIN --start recent 2>/dev/null | tail -20

# Confirm the account is not also expired/locked at the passwd layer
sudo passwd -S deploy
sudo chage -l deploy

faillock --user deploy is the key check: it lists each failed attempt with its source RHOST, which usually points straight at the misbehaving client or job.

Step-by-Step Resolution

1. Confirm it is faillock, not a disabled account. Run faillock --user deploy. If it lists failures up to or beyond deny=, faillock is the cause. passwd -S shows whether the account is also locked (L) at the shadow layer, which is a separate issue.

2. Identify the failure source. Read journalctl -u sshd for the RHOST and the credential type. A repeating IP usually means an automation job or a client offering a stale key.

3. Stop the source first. Reset the credential in the automation job, remove the stale key from the client’s agent, or pause the probe. Resetting the counter without fixing the source just re-locks the account.

4. Reset the faillock counter for the affected user once the source is fixed:

   sudo faillock --user deploy --reset

5. Verify the tally is clear and the user can authenticate:

   faillock --user deploy

6. Tune the policy if legitimate traffic keeps tripping it. In /etc/security/faillock.conf, prefer a modest deny with a reasonable cooldown, for example deny = 5 and unlock_time = 900 (15 minutes), and keep fail_interval sane so unrelated failures do not accumulate forever.

Prevention and Best Practices

• Set unlock_time so accidental lockouts self-heal in minutes rather than requiring manual resets.
• Use dedicated automation accounts with rotated, monitored credentials so one bad job cannot lock a human admin out.
• Alert on pam_faillock ... account temporarily locked in the journal so you catch the misbehaving source before the user reports it.
• Keep the faillock tally directory on local disk, not NFS, to avoid cross-host counter inconsistencies.
• Document the faillock --reset runbook so on-call engineers do not loosen deny= system-wide just to unblock one user.

Related Errors

• Account locked due to failed login attempts (pam_tally2) — the older module with the same behavior.
• sudo: PAM account management error — a PAM account phase rejection at escalation time.
• Authentication failure / Permission denied (publickey,password) — upstream SSH failures that feed the faillock counter.
• pam_unix(sshd:auth): authentication failure — the per-attempt log line that accumulates toward the lockout.

Frequently Asked Questions

The user swears their password is correct but they are still locked out. Once deny= is reached, faillock rejects even correct credentials until unlock_time elapses or you run faillock --reset. The password being right does not matter while the counter is tripped.

Where do I change the threshold? On modern systems, /etc/security/faillock.conf. Older configs set deny= and unlock_time= directly on the pam_faillock line in /etc/pam.d/.

Does resetting the counter weaken security? No. faillock --reset clears one user’s tally after you have addressed the cause. It does not change the policy that protects against repeated failures.

Why does root never get locked? Unless even_deny_root is set, root is exempt. Be cautious enabling it; you can lock yourself out of the console.

How do I find which IP is locking the account? faillock --user <name> lists the RHOST for each failure, and journalctl -u sshd correlates it with the credential type and timestamp.