ServerAvatar Logo
Start Free

How to Fix Too Many Authentication Failures Error in SSH

  • Author: Meghna Meghwani
  • Published: 14 August 2026
  • Last Updated: 14 August 2026
How to Fix Too Many Authentication Failures Error in SSH

Table Of Contents

Blog banner - ServerAvatar

Picture this: you’re in the middle of a deployment, and suddenly your SSH connection refuses to connect. The server returns a Too Many Authentication Failures error like:

Received disconnect from host: 2: Too many authentication failures for root

You have entered the correct password. You have the correct SSH key. Nothing appears to be wrong with your credentials, yet the connection keeps failing. This error can be confusing because “Too many authentication failures” doesn’t necessarily mean that you entered the wrong password too many times.

One of the most common causes is that your SSH client is offering multiple identities, often from your SSH agent, before it gets to the correct key. The server reaches its MaxAuthTries limit and closes the connection before successful authentication can occur.

In this guide, we will explain why this happens, how to diagnose the exact cause, and several ways to fix it, from the quickest command-line solution to a permanent SSH configuration. We will also cover how to prevent the problem in CI/CD environments and some additional SSH security practices.

Let’s dig in.

TL;DR

  • A common cause of “Too many authentication failures” is that the SSH client offers multiple identities before successful authentication.
  • OpenSSH’s MaxAuthTries controls how many authentication attempts are permitted per connection. Its default is commonly 6.
  • Having many keys loaded into ssh-agent does not automatically mean there is a problem. The important question is which identities SSH actually offers during the connection.
  • Quick fix: Specify the correct key and use IdentitiesOnly=yes:
ssh -o IdentitiesOnly=yes -i ~/.ssh/your_specific_key user@hostname
  • Recommended long-term fix: Configure IdentitiesOnly yes and IdentityFile for the host in ~/.ssh/config.
  • Increasing MaxAuthTries can be useful in specific environments, but it should generally be a last resort.
  • For automation and CI/CD, explicitly specify the intended SSH identity instead of allowing the client to try multiple keys.
         SSH Client
             │
             ├── Work Key
             ├── GitHub Key
             ├── AWS Key
             ├── Old Key
             └── Correct Server Key
                    │
                    ▼
                SSH Server
                    │
                MaxAuthTries = 6
                    │
                    ▼
        Too many authentication failures

What Does “Too Many Authentication Failures” Actually Mean?

The error message can make it sound like you’ve simply entered an incorrect password too many times. That’s not necessarily what happened.

A common scenario looks like this:

  • Your SSH client has multiple identities available.
  • Some of those identities may come from ssh-agent.
  • SSH offers identities to the server during authentication.
  • The server rejects identities that aren’t authorized for the target account.
  • The number of authentication attempts reaches the server’s MaxAuthTries limit.
  • The server terminates the connection before the correct identity is successfully used.

OpenSSH’s MaxAuthTries setting controls the maximum number of authentication attempts permitted per connection. The default is commonly 6. The exact value can be changed by the server administrator.

You can refer to the OpenSSH sshd_config documentation for the current behavior and default values.

For example, imagine your SSH agent contains several keys:

work-key
github-key
aws-key
old-project-key
personal-key
server-key

Your intended server-key may be valid for the destination server, but if SSH offers several other identities first, the server may reach its authentication-attempt limit before the correct key gets a chance to authenticate.

This is why you can have a perfectly valid SSH key and still receive:

Too many authentication failures

Important clarification: Having more than six keys in your SSH agent does not automatically mean you will get this error.

The important thing is how many authentication attempts are actually made during the connection and how your SSH client and server are configured.

That’s why checking the verbose SSH output is important before changing server-side settings.

Why this matters for your fix: Most quick fixes just tell you to specify the key with -i. That’s not wrong, but it’s incomplete. The real fix is telling SSH to stop offering other keys entirely, which is what IdentitiesOnly yes does.

How SSH Agent Can Contribute to the Problem

An SSH agent such as ssh-agent can store multiple private-key identities so you don’t have to repeatedly enter passphrases.

You can check which keys are currently loaded with:

ssh-add -l

You might see something like:

256 SHA256:xxxx work-key (ED25519)
256 SHA256:xxxx github-key (ED25519)
256 SHA256:xxxx aws-key (ED25519)
256 SHA256:xxxx old-project-key (ED25519)
256 SHA256:xxxx personal-key (ED25519)

Having multiple keys isn’t inherently bad. The problem occurs when SSH offers identities that aren’t appropriate for the target server and consumes the server’s available authentication attempts before the correct identity succeeds.

This is one reason IdentitiesOnly yes is so useful. It allows you to tell SSH to use only the identity I explicitly configured for this host.

OpenSSH documents IdentitiesOnly specifically for situations where ssh-agent offers multiple identities.

How to Diagnose the Problem

Before changing your server configuration, it’s better to determine exactly what’s happening.

Step 1: Check Your SSH Agent

Run this on your local machine:

ssh-add -l

If you have many keys loaded, they could be contributing to the problem. However, don’t assume that the number of keys alone proves the cause. The next step is more useful.

Step 2: Use Verbose SSH Output

Run:

ssh -vvv user@hostname

The -vvv option enables detailed SSH debugging information. Look for lines similar to:

debug1: Offering public key: /home/user/.ssh/id_ed25519_work
debug1: Offering public key: /home/user/.ssh/id_ed25519_github
debug1: Offering public key: /home/user/.ssh/id_ed25519_aws

You may also see:

debug1: Authentications that can continue: publickey,password

The Offering public key messages can help you identify which identities the SSH client is attempting.

If several identities are being offered before the connection is terminated, that’s a strong indication that identity selection is contributing to the problem.

Step 3: Check Your Effective SSH Configuration

SSH configuration can come from multiple places, including:

  • ~/.ssh/config
  • /etc/ssh/ssh_config
  • command-line options
  • SSH agent configuration

You can inspect the effective client configuration for a host with:

ssh -G user@hostname | grep -i identity

This can help reveal which identity files SSH is configured to consider.

Step 4: Identify the Correct SSH Key

You need to determine which public key is actually authorized on the server.

If you have console access, another administrative account, or another out-of-band access method, inspect the target user’s authorized_keys file:

cat ~/.ssh/authorized_keys

as mentioned below:

check ssh configuration - Too Many Authentication Failures

On your local machine, you can

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Compare the fingerprint with the authorized key on the server.

If you don’t have SSH access to the server, use your hosting provider’s console or another available out-of-band access method to inspect the configuration.

Step 5: Check the Server’s MaxAuthTries Setting

If you have administrative access to the server, check the SSH daemon configuration:

sudo sshd -T | grp -i maxauthtries

This is often more useful than simply searching the configuration file because sshd -T displays the effective configuration.

You can also check /etc/ssh/sshd_config directly:

grep -i MaxAuthTries /etc/ssh/sshd_config

You may see:

#MaxAuthTries 6

as mentioned below:

maxauthtries - Too Many Authentication Failures

A commented-out setting generally means the default value is being used, unless another configuration file or included configuration overrides it.

Is my IP address banned after hitting MaxAuthTries?

Normally, no. MaxAuthTries limits authentication attempts for an individual SSH connection. Reaching the limit normally causes that connection to be terminated.

If your IP address is actually being blocked, another security mechanism may be responsible, such as:

  • Fail2ban
  • firewall rules
  • intrusion-prevention software
  • cloud security controls
  • other server-side security tooling

If you suspect an IP block, investigate those systems separately.

How to Fix “Too Many Authentication Failures” in SSH

Now that you understand why SSH can trigger the “Too many authentication failures” error, let’s look at the practical ways to resolve it.

The following fixes start with the quickest client-side solution and progress to permanent SSH configuration changes and server-side options when necessary.

Fix 1: Use IdentitiesOnly With the Correct Key

For most users, this is the quickest and safest solution. Specify the exact private key you want to use and tell SSH not to use other identities from the agent:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_server1 user@hostname

For example:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_server1 ubuntu@203.0.113.50

What does this command do?

-i specifies the identity file:

-i ~/.ssh/id_ed25519_server1

IdentitiesOnly=yes tells the SSH client to use only the explicitly configured identity files and certificates for authentication rather than freely using identities offered by the agent.

This combination is especially useful when your SSH agent contains multiple keys.

Why isn’t -i alone always enough?

Many users assume this:

ssh -i ~/.ssh/id_ed25519_server1 user@hostname

means SSH will use only that key. However, SSH can also consider identities available through the agent depending on the configuration.

Using:

-o IdentitiesOnly=yes

makes the intended identity selection explicit.

Quick fix:

If you’re currently locked out because the client is offering too many identities, try:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_server1 user@hostname

If the specified key is authorized for that account, this can immediately resolve the problem.

Fix 2: Configure SSH for a Permanent Per-Host Solution

If you regularly manage multiple servers, typing the full command every time isn’t ideal. A better approach is to configure SSH per host. Open or create your SSH configuration file:

nano ~/.ssh/config

Add an entry like this:

Host server1
    HostName 203.0.113.50
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_server1
    IdentitiesOnly yes

For another server:

Host server2
    HostName server2.example.com
    User admin
    IdentityFile ~/.ssh/id_ed25519_server2
    IdentitiesOnly yes

Now you can simply run:

ssh server1

SSH automatically knows:

  • which hostname to connect to
  • which user to use
  • which identity to use
  • which identities should be considered

This is one of the cleanest ways to prevent authentication failures caused by unintended identity selection.

Why IdentitiesOnly yes Matters

The important line is:

IdentitiesOnly yes

Without it, SSH may consider identities available through the agent in addition to the identity files configured for the host.

With it, you’re explicitly limiting the identities used for that host.

This is particularly helpful if you manage multiple servers, projects, clients, or cloud accounts from the same workstation.

SSH Config Permissions

It’s good practice to protect your SSH configuration and private keys. For example:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/config
chmod 600 ~/.ssh/id_ed25519_server1
chmod 644 ~/.ssh/id_ed25519_server1.pub

A private key should normally be readable only by its owner. The exact permission requirements can vary by operating system and SSH implementation, but restrictive permissions such as 600 are a safe standard choice for private keys.

Fix 3: Increase MaxAuthTries on the Server

Increasing MaxAuthTries is technically valid, but it should generally be considered a last resort.

If your SSH client is unnecessarily offering multiple identities, increasing the server limit doesn’t solve the underlying problem. It simply allows more authentication attempts before the server terminates the connection.

When might increasing it make sense?

There may be legitimate environments where multiple authentication attempts are expected.

For example, certain automated systems or specialized authentication setups may legitimately require several attempts.

If you’ve verified your client configuration and still need additional authentication attempts, you can consider increasing the value conservatively.

Step 1: Back Up the SSH Configuration

Before making changes:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

Step 2: Edit sshd_config

Open the configuration file:

sudo nano /etc/ssh/sshd_config

Find:

#MaxAuthTries 6

You could change it to a higher value, for example:

MaxAuthTries 10

Don’t blindly choose a value for production. Use a value appropriate for your environment and security requirements.

Allowing more authentication attempts can increase the opportunity for password or authentication guessing, so avoid increasing the value unnecessarily.

Step 3: Validate the SSH Configuration

Before restarting SSH, validate the configuration:

sudo sshd -t

If the command returns no output, the configuration syntax is generally valid.

Do not skip this step. A configuration error can prevent the SSH daemon from restarting correctly.

Step 4: Restart SSH

Based on the Linux distribution, the service may be named differently, sshd or ssh. For systems using sshd:

sudo systemctl restart sshd

For systems using ssh:

sudo systemctl restart ssh

Important safety tip:

Don’t close your only working SSH session while changing SSH configuration.

If possible:

  • Keep your existing SSH session open.
  • Validate the configuration.
  • Restart SSH.
  • Open a separate terminal.
  • Test a new SSH connection.

That way, if something goes wrong, you still have your existing session available for troubleshooting.

What About MaxStartups?

You may come across another SSH setting called:

MaxStartups

It’s important not to confuse it with MaxAuthTries. They control different things.

MaxAuthTries : Controls the number of authentication attempts allowed per connection.

MaxStartups : Controls the number of concurrent unauthenticated connections the SSH daemon allows.

For example:

MaxStartups 10:30:100

This is related to limiting concurrent unauthenticated connections, not the number of authentication attempts within a single connection.

Therefore, changing MaxStartups is not a replacement for fixing an identity-selection problem that causes Too many authentication failures.

Blog banner - ServerAvatar

How to Prevent the Error From Coming Back

Once you’ve fixed the immediate problem, it’s worth preventing it from happening again.

1. Configure One Appropriate Identity Per Host

The most important practice is not necessarily “one key per server.”

Instead:

Configure SSH so that each host receives only the identity it actually needs.

For example:

Host production
    HostName 203.0.113.50
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_production
    IdentitiesOnly yes

This prevents unrelated identities from being offered to the server.

Using separate keys for different servers, clients, or environments can also be a good security practice depending on your setup.

2. Keep Your SSH Agent Clean

You can list keys currently loaded in your agent:

ssh-add -l

To remove a specific key:

ssh-add -d ~/.ssh/old_key

To remove all keys:

ssh-add -D

Then add only the keys you currently need:

ssh-add ~/.ssh/id_ed25519_server1
ssh-add ~/.ssh/id_ed25519_server2

Don’t remove keys blindly if they’re required by other active workflows.

3. Use Ed25519 for New SSH Keys

When generating a new SSH key, Ed25519 is a good modern choice supported by current OpenSSH versions.

For example:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_server1 -C "Production server 1"

Notice that the filename matches the key type:

id_ed25519_server1

rather than using an id_rsa filename for an Ed25519 key.

4. Use SSH Agent for Passphrase-Protected Keys

If your private key has a passphrase, using an SSH agent can make authentication more convenient. The goal isn’t to avoid using an SSH agent.

The goal is to control which identities SSH uses for each host.

For example:

Host production
    IdentityFile ~/.ssh/id_ed25519_production
    IdentitiesOnly yes

This lets you continue benefiting from an SSH agent without allowing every loaded identity to be tried against every server.

5. Configure CI/CD Deployments Explicitly

This error can also appear in automated environments such as:

  • GitHub Actions
  • GitLab CI/CD
  • Jenkins
  • deployment scripts
  • automation servers
  • infrastructure management tools

For automation, avoid relying on whichever keys happen to be loaded in an SSH agent.

Instead, explicitly specify the deployment key:

ssh -o IdentitiesOnly=yes -i /path/to/deploy_key user@hostname

For example:

ssh \
  -o IdentitiesOnly=yes \
  -o PasswordAuthentication=no \
  -i /path/to/deploy_key \
  deploy@hostname

Here, IdentitiesOnly=yes ensures the intended identity is selected, while PasswordAuthentication=no prevents the SSH client from falling back to password authentication.

The important option for this particular problem is:

IdentitiesOnly=yes

Common Mistakes That Make This Problem Worse

Adding More Keys

When SSH authentication fails, it’s tempting to add another key to the agent. That can make the problem worse.

Instead of continually adding identities, determine which key belongs to the server and explicitly configure SSH to use it.

Forgetting IdentitiesOnly

You may correctly specify:

IdentityFile ~/.ssh/id_ed25519_server1

but still experience identity-selection problems if your agent contains many other identities. For hosts where you want strict identity selection, use:

IdentitiesOnly yes

Assuming the Password Is Wrong

The error doesn’t necessarily mean the password is incorrect. If you’re using public-key authentication, the failure can happen before SSH ever gets to the authentication method you expected.

Use:

ssh -vvv user@hostname

to see what the client is actually doing.

Changing MaxAuthTries First

Increasing the server’s authentication-attempt limit may make the error disappear, but it doesn’t address the underlying client configuration.

First try:

ssh -o IdentitiesOnly=yes -i ~/.ssh/correct_key user@hostname

If that works, configure the host permanently in ~/.ssh/config.

Restarting SSH Without Testing the Configuration

Never make changes to /etc/ssh/sshd_config and immediately restart SSH without validating the configuration.

First run:

sudo sshd -t

And whenever possible, keep an existing SSH session open while testing the new configuration.

Additional SSH Hardening Steps

Fixing Too many authentication failures is only one part of securing SSH.

Once your authentication configuration is working, consider additional hardening appropriate for your environment.

Disable Direct Root Login

If your environment doesn’t require direct root SSH access:

PermitRootLogin no

Instead, use a regular administrative user and elevate privileges with sudo. Make sure you have tested the alternative administrative access before disabling root login.

Disable Password Authentication When Appropriate

If your environment is configured for SSH keys only, you can consider:

PasswordAuthentication no
KbdInteractiveAuthentication no

This prevents password and keyboard-interactive authentication methods from being used. However, don’t apply these settings blindly. Verify that your key-based authentication works first, or you could lock yourself out.

Consider Changing the SSH Port

Moving SSH away from the default port 22 can reduce automated scanning and login noise.

For example:

Port 2222

However, changing the port is not a substitute for proper SSH security. Strong authentication, least privilege, firewall rules, monitoring, and timely security updates remain much more important.

Consider SSH Certificates for Larger Environments

If you’re managing a larger infrastructure, SSH certificates can simplify centralized user and host authentication.

Instead of distributing individual public keys everywhere, an organization can use a trusted SSH certificate authority to issue certificates.

This can make access management easier at scale, but it introduces additional infrastructure and operational complexity.

For a small number of servers, traditional SSH public-key authentication with a well-managed ~/.ssh/config is often sufficient.

Key Takeaways

  • The “Too many authentication failures” error doesn’t necessarily mean your password or SSH key is incorrect.
  • A common cause is that the SSH client offers multiple identities before reaching the correct key.
  • OpenSSH’s MaxAuthTries setting limits the number of authentication attempts allowed per connection.
  • Use IdentitiesOnly=yes with the correct private key to prevent SSH from unnecessarily trying other identities.
  • Configure IdentityFile and IdentitiesOnly yes in ~/.ssh/config for a permanent, per-server solution.
  • Increasing MaxAuthTries can help in specific cases, but it should generally be a last resort rather than the first fix.
  • For CI/CD and automation, explicitly specify the deployment key to avoid authentication failures caused by multiple identities.
  • Regularly review your SSH agent and remove keys that are no longer needed.

If you’re setting up a new VPS for application hosting, you can also connect a self-managed server from any cloud provider to ServerAvatar and manage it through the ServerAvatar panel.

Conclusion

The “Too many authentication failures” error can be frustrating because it often occurs even when you have the correct SSH credentials. In many cases, the problem isn’t the key itself but the number of identities your SSH client attempts during authentication. By using verbose SSH output to identify the identities being offered and specifying the correct key with IdentitiesOnly=yes, you can usually resolve the issue without making changes to the server.

For a long-term solution, configure each server in your ~/.ssh/config with the appropriate IdentityFile and IdentitiesOnly yes settings. Avoid increasing MaxAuthTries unless your environment genuinely requires additional authentication attempts. With proper SSH identity management and host-specific configuration, you can prevent this error from recurring while maintaining a secure and reliable SSH setup.

FAQs

Why am I getting “Too many authentication failures” in SSH?

This error commonly occurs when your SSH client offers multiple identities during authentication and the server reaches its MaxAuthTries limit before the correct key is accepted. It doesn’t necessarily mean that your password or SSH key is incorrect.

How do I fix “Too many authentication failures” in SSH?

The quickest solution is to specify the correct private key and use IdentitiesOnly=yes:

ssh -o IdentitiesOnly=yes -i ~/.ssh/your_key user@hostname

This prevents SSH from unnecessarily trying other identities from your SSH agent.

What does IdentitiesOnly yes do in SSH?

IdentitiesOnly yes tells the SSH client to use only the identities explicitly configured for the connection instead of freely using additional identities offered by the SSH agent. It’s particularly useful when you manage multiple SSH keys.

How can I permanently prevent this SSH error?

Add the server to your ~/.ssh/config file and specify the correct identity:

Host myserver
HostName 203.0.113.50
User ubuntu
IdentityFile ~/.ssh/id_ed25519_myserver
IdentitiesOnly yes

You can then connect using:

ssh myserver

Should I increase MaxAuthTries to fix the problem?

Increasing MaxAuthTries can be appropriate in specific environments, but it shouldn’t be your first solution. If the client is offering unnecessary SSH keys, it’s better to fix the client-side identity configuration with IdentitiesOnly=yes.

How can I check which SSH keys are being offered?

Run SSH with verbose output:

ssh -vvv user@hostname

Look for messages such as:

Offering public key:

These messages show which identities the SSH client is attempting during authentication.

If you’re managing multiple Linux servers, a server management platform such as ServerAvatar can simplify many routine server-management tasks

About the Author

Meghna Meghwani is a technical writer focused on Linux, Ubuntu, VPS hosting, server management, WordPress, PHP, Node.js, cloud hosting, and DevOps. She creates beginner-friendly tutorials, practical hosting guides, troubleshooting articles, and server security content designed to help developers and businesses manage applications and servers more efficiently.

Deploy your first application in 10 minutes, Risk Free!

Learn how ServerAvatar simplifies server management with intuitive dashboards and automated processes.
Get Started Now
  • No CC Info Required
  • Free 4-Days Trial
  • Deploy in Next 10 Minutes!