How to fix Received disconnect from host: 2: Too many authentication failures in SSH

SSHINTERMEDIATEMEDIUMUpdated Jan 4, 2026· 333 views

This error occurs when the SSH client tries too many authentication methods before the server's maximum attempt limit is reached. The server disconnects to prevent brute force attacks. Usually caused by offering too many SSH keys or having multiple identity files configured.

Quick fix

Fixes Received disconnect from host: 2: Too many authentication failures

ssh -i ~/.ssh/your_specific_key user@hostname
  1. Specify the correct identity file explicitly
  2. Add IdentitiesOnly to your SSH config
  3. Clear ssh-agent and add only the needed key
  4. Disable ssh-agent temporarily for a single connection
ssh — error
ssh -i ~/.ssh/your_specific_key user@hostname
Received disconnect from host: 2: Too many authentication failures

What this error means

SSH servers have a security limit (MaxAuthTries) that restricts how many authentication attempts are allowed per connection before disconnecting. The default is typically 6 attempts. When you have many SSH keys loaded in your SSH agent or multiple IdentityFile entries configured, the SSH client tries each one sequentially. If it exhausts all keys before reaching the correct one, or if there are too many incorrect attempts, the server forcefully disconnects with this error to prevent brute force attacks.

Typical symptoms

  • SSH connection succeeds initially but is immediately disconnected with 'Too many authentication failures'
  • Manual SSH connection with password works fine but key-based auth fails
  • SSH works fine on one machine but fails on another
  • SSH fails only when connecting to certain hosts but works to others
  • Error happens during CI/CD pipelines or automated scripts
  • SSH works after disconnecting ssh-agent or clearing loaded keys

Common causes

  1. Too many SSH keys loaded in ssh-agent (exceeds server's MaxAuthTries limit, default 6)
  2. Multiple IdentityFile entries in ~/.ssh/config for the same host
  3. Incorrect SSH keys being tried before the correct one
  4. SSH agent offering unrelated keys from other deployments or projects
  5. Server has a restrictively low MaxAuthTries setting (less than 3)
  6. Recent system updates changed default SSH key ordering
  7. Using SSH with multiple identities (e.g., work + personal accounts)

How to fix "Received disconnect from host: 2: Too many authentication failures"

1Specify the correct identity file explicitly

Use the -i flag to tell SSH exactly which key to use, bypassing the agent:

bash
ssh -i ~/.ssh/your_specific_key user@hostname

This prevents SSH from trying multiple keys and exhausting the authentication limit. If this works, the issue is key selection, not the connection itself.

2Add IdentitiesOnly to your SSH config

Configure SSH to use only the explicitly specified identity files, not all keys in the agent:

bash
Host your-server.com
    HostName your-server.com
    User username
    IdentityFile ~/.ssh/specific_key
    IdentitiesOnly yes

The IdentitiesOnly yes directive tells SSH to ignore other keys in ssh-agent and use only the configured IdentityFile. This is the cleanest long-term solution.

3Clear ssh-agent and add only the needed key

Remove all loaded keys from your SSH agent and add back only the one you need:

bash
# Clear all keys from agent
ssh-add -D

# Add only the specific key you need
ssh-add ~/.ssh/your_specific_key

Then try SSH again:

bash
ssh user@hostname

This temporarily solves the issue but resets when you restart your system or open a new terminal. Use the ~/.ssh/config approach (step 2) for a permanent fix.

4Disable ssh-agent temporarily for a single connection

Force SSH to bypass the agent entirely for one connection:

bash
SSH_AUTH_SOCK= ssh -i ~/.ssh/your_key user@hostname

This unsets the SSH_AUTH_SOCK environment variable, preventing SSH from accessing the agent. Useful for troubleshooting when you want to test without agent interference.

5Use PreferredAuthentications to force password auth

If you want to bypass key authentication temporarily and use password instead:

bash
ssh -o PreferredAuthentications=password user@hostname

This is helpful for testing whether the issue is with key authentication or something else. After confirming password auth works, you can focus on fixing the key setup.

6List and clean up unused SSH keys

See what's currently in your SSH agent:

bash
ssh-add -l

Remove keys you no longer use:

bash
ssh-add -d ~/.ssh/old_key

Or delete the key files entirely if you're certain they're no longer needed:

bash
rm ~/.ssh/old_key ~/.ssh/old_key.pub

Fewer loaded keys means fewer authentication attempts, reducing the chance of hitting the limit.

7Increase MaxAuthTries on the server (if you have access)

If you control the SSH server, you can increase the authentication attempt limit in /etc/ssh/sshd_config:

bash
# Edit the SSH daemon config
sudo nano /etc/ssh/sshd_config

Find or add the line:

bash
MaxAuthTries 10

Then restart SSH:

bash
sudo systemctl restart ssh
# or on some systems:
sudo service sshd restart

Warning: Setting MaxAuthTries too high reduces security against brute force attacks. Only increase it if you have a legitimate reason (e.g., systems with many keys in production).

8Verify SSH key permissions

Ensure your private keys have proper permissions (600). Keys with wrong permissions can cause authentication failures:

bash
chmod 600 ~/.ssh/your_key

List and verify:

bash
ls -l ~/.ssh/your_key

Should show: -rw------- 1 user group (permissions 600)

Incorrect permissions are a common cause of SSH auth failures.

Advanced notes

Advanced troubleshooting:

SSH Agent Forwarding Issues: When using ssh-agent forwarding (-A flag), keys from your local agent are offered to remote hosts. If the remote host also has its own agent running, you might see cascading authentication failures. Use ssh-add -l locally to verify what's being forwarded.

Container and VM Environments: Docker containers, Kubernetes pods, and VMs often have fresh SSH agents without your keys. Use explicit key paths (-i flag) or mount SSH config directories rather than relying on agent forwarding.

Git over SSH Complications: If you're using git over SSH in CI/CD, the git client bypasses your SSH config. Use explicit key configuration in your git config or pass the key via SSH_KEY_PATH environment variables.

Security Group Timeouts: On AWS and cloud platforms, security group rules might be blocking SSH traffic or allowing it only from certain IPs. If the connection is hanging before showing the "too many auth failures" error, check security group and firewall rules.

Debugging with Verbose Logging: Use ssh -vvv user@host to see detailed authentication negotiation. Look for the exact methods being attempted and where it fails. This helps distinguish between "too many keys" vs "wrong key" problems.

ECDSA vs RSA Key Issues: If you have mixed key types (RSA, ECDSA, ED25519), the server's key algorithm preferences might skip your key. Explicitly specify key type with -o HostKeyAlgorithms=ssh-ed25519 if needed.

Frequently asked questions

What does "Received disconnect from host: 2: Too many authentication failures" mean?
SSH servers have a security limit (MaxAuthTries) that restricts how many authentication attempts are allowed per connection before disconnecting. The default is typically 6 attempts. When you have many SSH keys loaded in your SSH agent or multiple IdentityFile entries configured, the SSH client tries each one sequentially.
How do I fix "Received disconnect from host: 2: Too many authentication failures"?
This error occurs when the SSH client tries too many authentication methods before the server's maximum attempt limit is reached. The server disconnects to prevent brute force attacks. Usually caused by offering too many SSH keys or having multiple identity files configured.
What causes "Received disconnect from host: 2: Too many authentication failures"?
Too many SSH keys loaded in ssh-agent (exceeds server's MaxAuthTries limit, default 6) Multiple IdentityFile entries in ~/.ssh/config for the same host Incorrect SSH keys being tried before the correct one
Is the "Received disconnect from host: 2: Too many authentication failures" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading