Too Many Authentication Failures

Too Many Authentication Failures happens when an SSH server hits its try limit because the client offers too many keys or methods before the right one.

This error often lands when you are trying to deploy, pull a repo, or hop onto a box to check logs. You type the same command you always type, then the connection drops. No prompt. No second chance. Just a disconnect line that makes it feel like you did something wrong.

In most cases, the server is not “mad” at you and your credentials are not suddenly bad. The server is counting failed authentication attempts inside a single SSH connection. If your client offers a long list of identities before it gets to the correct one, the server cuts the session once the limit is reached.

The fix is usually simple: stop the client from trying every key it can see. Pick the right key on purpose. Then lock that behavior into your SSH config so the problem does not bounce back when you change terminals, IDEs, or automation.

What This Error Means In Plain Terms

SSH can try multiple authentication methods during one connection. Public key auth is the common path, but your setup may also allow password prompts, keyboard-interactive prompts, or other methods. Each attempt can count toward a per-connection try limit on the server.

The trap shows up when your client has many keys available. A typical cause is an agent loaded with several identities. The SSH client may offer them one by one. The server treats each rejected key as a failed attempt, even if the correct key is still in the list.

So the server is not blocking you forever. It is ending that one connection. If you reconnect with the right identity pinned from the start, you can often log in on the first try.

What You See	Likely Cause	Fast Fix
Disconnect after several “Offering public key” lines	Too many agent keys offered	Use IdentitiesOnly with one IdentityFile
No password prompt, then disconnect	Key offers exhaust tries first	Point to the right key with -i
Works in one terminal, fails in another	Different agent or keychain state	List loaded keys, then remove extras
Fails only in an IDE or Git client	Tool loads extra identities	Set per-host SSH config for that host

Too Many Authentication Failures In SSH

Before changing anything, confirm you are hitting the server’s authentication try limit and not a network or firewall issue. The quickest way is to run SSH in verbose mode and watch what identities are being offered.

Run verbose SSH — Use ssh -v user@host and read the authentication lines before the disconnect.
Run extra verbose SSH — Use ssh -vvv user@host to see agent and identity selection in more detail.

If you see many “Offering public key” lines in a row, you are likely burning tries on keys that do not match the server. If the session ends right after those offers, the pattern is clear.

Next, check what your agent is holding. A long identity list is the usual reason the client is spamming the server with offers.

List agent identities — Run ssh-add -l to see how many keys your agent will offer.
Print public keys — Run ssh-add -L to see which public keys are loaded.

When you confirm the agent is loaded with many keys, treat the fix as a routing problem. You are not “fixing SSH” in general. You are teaching the client which identity to present to this host first.

Fix The Client First With One Known Identity

The most dependable fix is to make SSH deterministic. That means telling the client which key to use for a host and telling it not to offer anything else. This also prevents tools that call SSH behind the scenes from repeating the mistake.

Use A One-Off Command To Pin The Key

If you need access right now, pick the correct private key file directly in your command. This bypasses a lot of agent noise.

Pick the identity file — Run ssh -i ~/.ssh/id_ed25519 user@host with the correct key path.
Block other identities — Add -o IdentitiesOnly=yes so SSH will not offer extra keys.
Retry cleanly — Start a new connection after the first disconnect, not inside the same session.

This one-liner is also a strong test. If it works, you have proven the server accepts your key and the earlier failures were caused by the client offering too many identities.

Lock It In With A Per-Host SSH Config Block

For a host you use more than once, set up a dedicated host block in ~/.ssh/config. SSH matches config blocks by the host string you type, so keep that host string consistent.

Create a Host entry — Add a block like Host my-server that matches the name you actually type.
Set HostName — Add HostName with the real DNS name or IP address.
Pin one key — Add IdentityFile to the correct private key file.
Force a single identity — Add IdentitiesOnly yes to stop extra offers.
Set user consistently — Add User so tools do not guess the wrong account name.

Once the host block is in place, the same fix applies to Git, deployment scripts, and editor integrations. They call SSH, and SSH follows your config.

Trim Your Agent When It Holds Too Many Keys

Agents are useful, but they can turn into a pile of identities you no longer need. If your agent offers a long list, it is easy to hit the server limit before your correct key is tried.

Remove one identity — Run ssh-add -d ~/.ssh/old_key to delete a single key from the agent.
Clear the agent — Run ssh-add -D to remove all identities from the agent.
Add only what you need — Run ssh-add ~/.ssh/id_ed25519 to keep the list short.

After trimming, reconnect with verbose mode once. You should see far fewer “Offering public key” lines, and the correct identity should appear early.

Server-Side Changes That Reduce Friction Without Getting Loose

Client-side fixes solve most cases. If you also manage the server, there are server-side settings that can reduce lockouts when users have multiple auth methods. Use caution with these changes. Raising limits can give attackers more room inside one connection.

Review MaxAuthTries And Keep It Modest

On OpenSSH servers, the MaxAuthTries setting controls the maximum number of authentication attempts allowed per connection. Many setups use a default of 6. If users are offering multiple identities before the correct one, that default can be tight.

Edit sshd_config — Open /etc/ssh/sshd_config with root access.
Set MaxAuthTries — Choose a value that matches your real login flow, not a high number.
Reload sshd — Reload the SSH service so the change takes effect.

If you raise this limit, pair it with other guardrails like allowing only key-based auth for normal users, limiting which accounts can log in, and using rate limiting at the network edge.

Cut Methods You Do Not Use

Each enabled method is another path the client may try, and those tries can burn the connection budget. If your server has methods enabled that your team never uses, disable them.

Disable password auth — Set PasswordAuthentication no when passwords are not part of your access model.
Disable interactive prompts — Set KbdInteractiveAuthentication no if you do not use that method.
Limit allowed accounts — Use AllowUsers or AllowGroups to restrict who can attempt login.

This change can also make debugging easier because the client will stop trying methods that are not supposed to work in the first place.

Common Root Causes And How To Spot Each One

The same message can come from a few patterns. The fastest way to sort them is to match your verbose output to the setup that caused it.

Agent Has A Long Key List

This is the classic reason. You have keys for several repos, cloud hosts, past work, and lab servers. The client offers them in some order. The server rejects the early ones, counts them, then ends the connection before the correct one is offered.

Confirm with -vvv — Look for many identity offers in a row before the disconnect.
Force one identity — Use IdentitiesOnly yes with a single IdentityFile for that host.
Keep the agent small — Clear and re-add only the identities you actually use.

If you see the phrase “too many authentication failures” after a stream of key offers, the fix is almost always on the client side.

Agent Forwarding Creates Extra Offers Across Hops

Agent forwarding can multiply the problem on jump hosts. You connect to a bastion, then connect onward to another host. If keys are forwarded and the jump host also has its own identities, the number of offers can spike.

Disable forwarding for a host — Set ForwardAgent no in the host block for the target.
Use ProxyJump cleanly — Use ProxyJump and pin an identity per hop.
Verify local agent state — Run ssh-add -l locally and trim the list before connecting.

A clean hop setup should offer a short list of identities on each connection, not a mix of everything from every layer.

Host Alias Mismatch Skips The Config Block

SSH config blocks match the host name you type, not the host’s “real name” in DNS. If you type 10.0.0.12 today and web-prod tomorrow, you may be bypassing the block that pins your identity.

Use one stable alias — Create a Host alias like web-prod and always use it.
Set HostName — Point that alias at the real IP or DNS name using HostName.
Set User — Put the account name in the block so tools do not guess.

If you keep host naming consistent, the same identity selection rules apply every time.

IDE Or Git Client Loads Extra Identities

Some apps ship their own SSH integration. They may load keys from a vault, start a separate agent, or import identities from the OS key store. That can change which identities are offered compared to a plain terminal.

Test from a plain shell — Compare results between your terminal and the tool that fails.
Point the tool at OpenSSH — Configure it to use your system SSH client and config file.
Disable built-in key loading — Turn off automatic key import if it keeps adding identities.

Once the tool uses your normal OpenSSH config, it should follow the same pinned identity rules as your terminal.

Hardening Steps So It Stays Fixed

After you regain access, take a few minutes to clean up your identity flow. You want each host to have one intended key, and you want your agent to hold only active identities.

Make A Small Key Inventory

A surprising number of lockouts come from not knowing which keys exist on your machine. A simple inventory helps you remove old keys and name the ones you still use.

List files in ~/.ssh — Check for private keys and confirm they have matching .pub files.
Check fingerprints — Run ssh-keygen -lf ~/.ssh/id_ed25519.pub and store the fingerprint in your notes.
Remove stale entries — Delete config blocks and agent loads that point to keys you no longer use.

Give Each System Its Own Alias

Aliases make identity selection predictable. They also cut down on copy-paste mistakes when you maintain multiple servers that look similar.

Create clear host names — Use names like prod-api, stage-api, and home-nas.
Pin a single IdentityFile — Keep one key per alias and keep IdentitiesOnly yes.
Store port and user — Put Port and User in the block to keep commands short.

Keep Authentication Paths Clean On The Server

If you control the server, keep its auth paths aligned with how your team actually logs in. Fewer methods, fewer surprises, and fewer chances to burn tries on a method that will never succeed.

Prefer key auth — Use modern key types like Ed25519 where your platform supports it.
Restrict password access — If passwords exist as a break-glass path, limit it to a small admin group.
Check logs after changes — Confirm the server sees the expected method and identity flow.

If you see the phrase “too many authentication failures” in incident notes, write down what changed on the client. It is often a new agent, a new IDE setting, or a new key import that expanded the identity list.

Quick Fix Checklist For A Two-Minute Recovery

If you need the shortest path, use this sequence. It avoids server changes and focuses on making the client present the correct identity first.

Run ssh -vvv — Confirm many identities are being offered before the disconnect.
Pin one identity — Run ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@host.
Clear the agent — Run ssh-add -D if extra identities keep showing up.
Add only the needed key — Run ssh-add ~/.ssh/id_ed25519 and retry.
Write a host block — Add a per-host config entry so the fix sticks for tools too.

Once your client offers a short identity list, logins become steady again. The connection stops failing mid-stream, and you stop losing time to random disconnects.