Fix SSH Too Many Authentication Failures Error (2026)

The SSH daemon (sshd) is refusing new connections because a specific IP address or user account has exceeded the allowed number of failed authentication attempts. This is a security measure to prevent brute-force attacks, but it can lock out legitimate users if misconfigured or if a user genuinely forgets their password.

Here are the common culprits and how to fix them:

1. Client-Side Brute-Force Attempt (Most Common)

Diagnosis: Check the sshd logs on the server for repeated connection attempts from a single IP address, often with varying usernames or incorrect passwords.
```
sudo grep "Failed password" /var/log/auth.log | tail -n 50
```
or on RHEL/CentOS:
```
sudo grep "Failed password" /var/log/secure | tail -n 50
```
Look for a consistent IP address showing up many times.
Fix: Identify and block the offending IP address on the server using iptables or firewalld. For iptables:
```
sudo iptables -A INPUT -s <offending_ip_address> -j DROP
sudo service iptables save # Or equivalent for your distro
```
For firewalld:
```
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="<offending_ip_address>" reject'
sudo firewall-cmd --reload
```
This works by instructing the server’s firewall to silently discard all incoming packets from that specific IP, preventing any further communication.

2. Incorrect SSH Key Permissions on the Server

Diagnosis: If you’re using SSH keys, incorrect permissions on the ~/.ssh directory or ~/.ssh/authorized_keys file on the server can cause sshd to reject authentication, even with the correct key. Check permissions on the server:
```
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys
```
The ~/.ssh directory should be 700 (drwx------) and ~/.ssh/authorized_keys should be 600 (-rw-------). The user’s home directory (~) should not be group-writable.
Fix: Correct the permissions on the server.
```
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R <username>:<username> ~/.ssh # Ensure correct ownership
```
This fixes the issue by ensuring that only the owner of the SSH key can read, write, or execute the necessary files, which is a security requirement for sshd.

3. Client-Side SSH Configuration Issues

Diagnosis: The client machine might be trying to connect using an incorrect username or an expired SSH key repeatedly. Check your local SSH client configuration (~/.ssh/config) and the SSH agent (ssh-add -l). On your local machine:
```
cat ~/.ssh/config
ssh-add -l
```
Look for any misconfigured HostName, User, or IdentityFile directives.
Fix: Correct your ~/.ssh/config file or ensure the correct key is loaded into your SSH agent. Example ~/.ssh/config fix:
```
Host my-server
    HostName 192.168.1.100
    User correct_username
    IdentityFile ~/.ssh/my_correct_key
```
If using ssh-agent, ensure the correct key is added:
```
ssh-add ~/.ssh/my_correct_key
```
This resolves the problem by making sure the client is presenting the correct credentials (username, hostname, and key) to the server for each connection attempt.

4. PAM Configuration on the Server

Diagnosis: The Pluggable Authentication Modules (PAM) system on the server might be configured with a very low limit for authentication attempts. Check the relevant PAM configuration file, often /etc/pam.d/sshd.
```
sudo cat /etc/pam.d/sshd
```
Look for lines related to pam_tally2.so or faillock.so. For example, you might see auth required pam_tally2.so onerr=succeed deny=5 unlock_time=900.
Fix: Adjust the deny and unlock_time parameters in /etc/pam.d/sshd. If using pam_tally2.so, change deny=5 to a higher number (e.g., deny=10) and unlock_time=900 (15 minutes) to unlock_time=0 (never auto-unlock, manual reset required) or a longer duration.
```
# Example change:
auth required pam_tally2.so onerr=succeed deny=10 unlock_time=3600
```
This increases the threshold for failed attempts before lockout and/or changes how long a user/IP is locked out, preventing accidental lockouts from minor typos.

If using faillock.so (more modern):
```
sudo pam-auth-update # To check current PAM configuration
```
Edit /etc/security/faillock.conf or /etc/pam.d/sshd to adjust deny and unlock_time. Example /etc/security/faillock.conf:
```
# Increase deny count and unlock time
deny = 10
unlock_time = 3600
```
This achieves the same goal by configuring the faillock module to allow more failed attempts before imposing a lockout.

5. Incorrect Username or Password on the Server

Diagnosis: The user account on the server simply has the wrong password set, or the user is trying to log in with a username that doesn’t exist. Log in directly on the server console or via another method to check user accounts and passwords.
```
sudo passwd <username>
```
(This will prompt you to set a new password if you are root or have sudo privileges).
Fix: Reset the password for the user account on the server.
```
sudo passwd <username>
```
Enter a new, correct password. This directly resolves the issue by providing valid credentials for authentication.

6. SSH Server Configuration (MaxAuthTries)

Diagnosis: The sshd_config file on the server might have a very low MaxAuthTries setting.
```
sudo grep MaxAuthTries /etc/ssh/sshd_config
```
If this line exists and is set to a low number (e.g., MaxAuthTries 3), it’s a likely cause.
Fix: Increase the MaxAuthTries value in /etc/ssh/sshd_config.
```
# Example: Increase to 6
MaxAuthTries 6
```
After editing, restart the sshd service:
```
sudo systemctl restart sshd
```
This tells the SSH daemon to allow more individual authentication attempts (e.g., password or key checks) per connection before it considers the session failed and logs the "Too Many Authentication Failures" error.

7. IP Address Blocked by fail2ban or Similar Tools

Diagnosis: If you have fail2ban or a similar intrusion-prevention system installed, it might have automatically banned the IP address after detecting too many failed attempts. Check fail2ban status and logs:
```
sudo fail2ban-client status sshd
sudo grep <offending_ip_address> /var/log/fail2ban.log
```
Fix: Unban the IP address using fail2ban-client.
```
sudo fail2ban-client set sshd unbanip <offending_ip_address>
```
This tells fail2ban to remove the IP address from its ban list, allowing connections to resume.

After resolving these issues, the next error you’re likely to encounter is a "Permission denied (publickey,password)." message if your SSH keys are still not correctly set up or if you’ve forgotten the actual password.

More Deep Dives in Ssh