Dennis HilkLinux Fix LabDE

SSH, Security & Permissions

SSH exhausts authentication attempts before the right key

An agent with many keys can use up the server’s authentication limit. Check identity selection before increasing server-wide limits.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • SSH disconnects with too many authentication failures.
  • The intended key is listed after several other identities.

Relevant environment

OpenSSH client with ssh-agent or a key provider; connection-free configuration inspection.

Recognizable messages (synthetic examples)
sshd[921]: maximum authentication attempts exceeded for example from 192.0.2.10 port 50121 ssh2

A key-selection problem is one possibility; the server line does not identify which method consumed the attempts.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • The agent may offer unrelated keys before the authorized one.
  • Repeated password or keyboard-interactive failures may consume the same limit.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Lists fingerprints from the current agent; it does not print private keys or change the agent.

ssh-add -l

Interpret the result: A long list supports an identity-order issue. An agent connection error or an empty agent suggests a different authentication path.

Check 2

Replace HOSTNAME with the failing SSH alias. -G expands configuration without connecting.

ssh -G HOSTNAME

Interpret the result: Inspect identityfile, identitiesonly, identityagent and preferredauthentications; several IdentityFile entries remain eligible even with IdentitiesOnly.

Evidence-guided next steps

Select the intended identity for this host

If unrelated agent keys are the issue, use a host-specific IdentityFile and IdentitiesOnly yes. Test the same selection with ssh -o IdentitiesOnly=yes -i /path/to/key HOSTNAME. The command attempts a login; do not place it in unattended diagnostics.

Precautions: Use the existing private-key path; never paste key contents. Avoid changing defaults for every host.

Recovery / rollback: Remove the new host-specific options or restore the saved SSH configuration; a one-time command needs no file rollback.

Did this solution help you?

Share this solution#

Correct the account or authentication method

If the agent is not responsible, verify the username and the required authentication sequence with the server administrator. Use the authorized key/account pair or complete the required second factor rather than retrying passwords against an exhausted limit.

Precautions: Do not increase MaxAuthTries globally to accommodate an unbounded agent list.

Recovery / rollback: Restore the previous username or authentication-method setting if a host-specific change was incorrect.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.