This error occurs when an SSH client (or server) exceeds the maximum number of authentication attempts. The SSH daemon disconnects the connection to prevent brute force attacks and excessive failed login attempts.
When the SSH daemon (sshd) receives too many failed authentication attempts from a client connection, it disconnects to protect the server from brute force attacks. The server counts each authentication method attempt (publickey, password, keyboard-interactive, etc.) toward the MaxAuthTries limit. Once the threshold is reached, the server forcibly closes the connection. This is a security feature designed to block automated attack attempts and prevent attackers from repeatedly trying invalid credentials.
The most effective fix is to tell SSH to use a specific key file, bypassing the ssh-agent:
ssh -i ~/.ssh/correct_key.pem user@hostnameThis avoids trying multiple keys and ensures only the correct key is sent in the first attempt. Replace correct_key.pem with your actual key filename.
Add a Host section to ~/.ssh/config that specifies exactly which key to use and prevents offering others:
Host myserver
HostName example.com
User myuser
IdentityFile ~/.ssh/correct_key.pem
IdentitiesOnly yes
ConnectTimeout 10The critical setting is IdentitiesOnly yes, which tells SSH to only use the specified IdentityFile and ignore all keys in ssh-agent. Now connect simply with:
ssh myserverIf you have many keys loaded in ssh-agent, you can temporarily remove all of them and add back only the one you need:
# Remove all keys from the agent
ssh-add -D
# Add only the key you need
ssh-add ~/.ssh/correct_key.pemYou'll be prompted for the key's passphrase (if it has one). After this, SSH will only offer that single key when connecting, avoiding the MaxAuthTries limit.
To see what keys are currently loaded:
ssh-add -lIf you're trying to log in with a password instead of a key, you can skip the publickey attempts entirely:
ssh -o PubkeyAuthentication=no user@hostnameThis forces password authentication and avoids the client offering keys that don't match. You'll be prompted for the password instead.
Add this to your SSH config if you want it to persist:
Host myserver
HostName example.com
PubkeyAuthentication noMake sure the public key on your client matches what's configured on the server:
On your client machine, display your public key:
cat ~/.ssh/correct_key.pubThen, log into the server (or ask the administrator) and check if your public key is in ~/.ssh/authorized_keys:
grep "YOUR_PUBLIC_KEY_CONTENT" ~/.ssh/authorized_keysIf it's not there, you need to add it to the server's authorized_keys file:
echo "your-public-key-content" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keysAdd -v flags to SSH to see detailed debug output about which keys are being tried:
ssh -v user@hostnameFor even more detail:
ssh -vv user@hostname
ssh -vvv user@hostnameLook for lines like:
Trying private key: /home/user/.ssh/id_rsa
Trying private key: /home/user/.ssh/id_ed25519
Trying private key: /home/user/.ssh/id_ecdsaThis shows which keys are being attempted in what order. If you see many attempts and then "Disconnecting: Too many authentication failures", you know the issue is too many keys being tried.
If you're the server administrator and need to allow more authentication attempts, edit /etc/ssh/sshd_config:
sudo nano /etc/ssh/sshd_configFind the line MaxAuthTries (it may be commented out with #) and change it:
MaxAuthTries 10Then restart the SSH daemon:
sudo systemctl restart sshdWarning: Increasing this setting makes your server slightly more vulnerable to brute force attacks. Only do this if you have a specific reason (e.g., many automated keys being offered) and preferably combined with other security measures like disabling password authentication and using firewall rules.
Advanced troubleshooting:
Per-Connection Reset: MaxAuthTries is enforced per SSH connection, not globally. Each new connection resets the attempt counter. If you're testing multiple keys, you'll hit the limit per connection, not across all connection attempts.
SSH Agent Behavior: When using SSH agent forwarding or a local agent with many keys, the client automatically tries each key until one works or the limit is reached. The best practice is to use IdentitiesOnly yes with explicit IdentityFile entries in your SSH config to be explicit about which keys to try.
CI/CD Systems: In continuous integration pipelines (GitHub Actions, GitLab CI, Jenkins, etc.), if using SSH keys for git operations, configure the pipeline to use a specific key file rather than relying on ssh-agent defaults. Many CI systems have ways to inject SSH keys; read your platform's SSH documentation.
Kubernetes and Container SSH: When running SSH inside containers or Kubernetes pods, ensure the ssh-agent isn't trying to forward many keys. Prefer explicit key passing via environment variables or mounted secrets.
Older OpenSSH Versions: Very old SSH versions (pre-7.0) had different key exchange behavior and MaxAuthTries counting. If upgrading is possible, newer versions have more predictable behavior.
Load key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH
Connection closed by UNKNOWN port 65535
How to fix 'Connection closed by UNKNOWN port 65535' in SSH
Offending ECDSA key in /home/user/.ssh/known_hosts:line
How to fix "Offending ECDSA key in known_hosts" in SSH