Too Many Authentication Failures: Fix SSH Key Selection First

“Too many authentication failures” is a per-connection authentication-attempt limit, not proof that someone typed a bad password repeatedly. First capture the actual methods/keys offered, then inspect why the client selected them. Only after client selection and the effective server policy are understood should MaxAuthTries enter the diagnosis.

OpenSSH · Authenticationssh-agent · keysLast reviewed Sep 27, 2026

🎯 This guide matches when:

SSH prints Received disconnect ... Too many authentication failures or equivalent wording during authentication.You may be disconnected before receiving the password prompt you expected.Your machine has several SSH identities, an active agent, or host-specific keys.

Find what is consuming authentication attempts

Several keys are offered before disconnectForce the intended identity for one connection, then make the selection host-specific if it works.

Password/MFA is actually being attemptedPreserve the verbose evidence and investigate the applicable authentication method or server policy instead of assuming an agent-key problem.

Authentication succeeds, then SFTP failsThis is no longer an authentication-limit problem. Continue with the subsystem startup guide if that exact error appears.

Difficulty: Easy–ModerateRisk: Low when testing client-side first

🔎 Quick Check — see which identities SSH offers

ssh -vvv user@server

Read the authentication section around lines such as Offering public key. Also inspect the client's effective configuration for this destination and inventory keys exposed by the agent:

ssh-add -l

Verify: Determine whether several identities are offered before the disconnect. One connection can contain multiple authentication attempts.

ADSENSE · reserved slot after the first useful step

Why one SSH login can trigger “too many” failures

OpenSSH server configuration uses MaxAuthTries to limit authentication attempts permitted per connection; the current OpenSSH manual documents a default of 6. Separately, the client can obtain identities from configuration and an authentication agent. If unsuitable identities are tried first, the server can reach its attempt limit before the intended identity—or a later authentication method—is accepted.

IdentitiesOnly yes tells the OpenSSH client to limit authentication identities to those explicitly configured/selected rather than freely using additional agent/provider identities. It does not mean “exactly one key” when multiple IdentityFile entries are effective. That is why the effective identity set and the actual Offering public key sequence should be checked together.

Fix path #1 — force the intended key for one connection

Test the intended private key without changing global client or server settings:

ssh -i ~/.ssh/id_ed25519_work -o IdentitiesOnly=yes user@server

Replace the example path and account with the identity you already know should be authorized for this host.

Verify: If the explicit-key connection succeeds and verbose output no longer cycles through unrelated agent identities, key selection—not a need for a higher server attempt limit—was the useful finding.

Fix path #2 — make successful key selection host-specific

If the one-off test succeeds, scope the behavior to that host rather than changing every SSH connection:

Host myserver
    HostName server.example
    User alice
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

IdentityFile identifies the configured identity, while IdentitiesOnly yes prevents extra agent identities from being offered merely because the agent knows about them.

Verify: Check ssh -G myserver for the effective identity settings, then start a fresh ssh -vvv myserver connection and confirm the actual offered sequence is the intended one. If several IdentityFile entries are deliberately effective, do not claim IdentitiesOnly yes reduced the connection to one key.

If keys are not the cause: preserve the actual authentication branch

If verbose output does not show a sequence of unwanted keys, do not force this diagnosis. Record which methods the server offers and which method fails—password, keyboard-interactive/MFA, public key, or another configured mechanism. A disconnect before a password prompt is not proof that the password itself was wrong.

Verify: Match the failure to the method visible in verbose client output and server authentication logs before changing authentication policy.

When to investigate MaxAuthTries on the server

Administrators can inspect the applicable server configuration after client-side identity selection has been ruled out. MaxAuthTries is a server policy control, not a generic client repair. Raising it can allow more attempts per connection and may simply hide poor key selection.

Do not infer the applicable value from one raw config line when Include/Match rules are present. Where supported, inspect sshd's effective configuration for the affected user/host/address context. If a server change is actually justified, make the minimum scoped change, keep an existing administrative session open, and validate before reload:

sudo sshd -t

Verify: A separate new connection authenticates with the intended method, the verbose trace no longer exhausts attempts, and existing access controls still behave as designed. If the failure changes to Permission denied (publickey), MFA rejection, or another concrete error, stop diagnosing the authentication-attempt limit and follow that new failure class.

What not to do first

Do not increase MaxAuthTries merely because the client has too many loaded keys.Do not delete every identity from ssh-agent when a per-host identity selection can isolate the connection.Do not delete authorized_keys or regenerate keys before proving the intended key is wrong.Do not enable password authentication just to bypass a public-key selection problem.Do not disable MFA or other authentication controls to make the disconnect disappear.Do not edit and reload server authentication settings before validating the configuration and preserving a working admin session.Do not assume IdentitiesOnly yes means exactly one key when multiple IdentityFile entries are effective.Do not inspect only ssh-agent; client config, includes and host-specific IdentityFile entries can also determine the offered set.Do not treat a raw MaxAuthTries line as the effective policy when Match/Include criteria may apply.Do not keep diagnosing “too many authentication failures” after the connection advances to a different concrete authentication error.

Still failing? Capture this evidence

Before escalating, record:the exact disconnect/error wordingthe authentication portion of ssh -vvv, with host/user/key fingerprints redacted as neededthe output pattern from ssh-add -l without sharing private keyswhich explicit -i ... -o IdentitiesOnly=yes test was performed and its resultclient and server OpenSSH versionsthe authentication methods offered by the serverrelevant server authentication logs at the same timestampapplicable MaxAuthTries or Match policy if you administer the servereffective client identity settings from ssh -G for the exact destinationthe actual ordered Offering public key sequence from the failing connectioneffective server authentication policy for the affected connection context when Match/Include rules applythe first different authentication error if the attempt-limit disconnect disappears

References

Still stuck? Ask the community

Share the redacted authentication section of ssh -vvv, the number of agent identities and the result of an explicit-key test.

Keep it safe: never post passwords, private keys, tokens, or unredacted authentication logs.

Loading community discussion…