This error occurs when the SSH client offers too many keys to the server before finding the correct one. The SSH server disconnects after reaching its MaxAuthTries limit (default 6). The fix is to configure SSH to use only the correct key for your Git host.
The "Too many authentication failures" error occurs when Git tries to connect to a remote repository over SSH, but the SSH client offers too many keys before finding one the server accepts. Each rejected key counts as a failed authentication attempt, and SSH servers have a limit (MaxAuthTries, typically 6) on how many attempts are allowed before disconnecting. This commonly happens when you have multiple SSH keys loaded in your ssh-agent. For example, if you have keys for GitHub, GitLab, personal servers, and work machines, the SSH client will try each one in sequence. If the correct key isn't among the first few tried, the server disconnects before reaching it. The error can appear as: - "Received disconnect from host: Too many authentication failures" - "Too many authentication failures for git" - "Connection reset by peer" (with verbose mode showing multiple key attempts) This is particularly common when using Git with multiple services (GitHub, GitLab, Bitbucket) or when working with both personal and enterprise accounts that each require different SSH keys.
First, identify which keys SSH is offering and in what order. This helps you understand why authentication is failing.
Run SSH with verbose output:
# Test connection to GitHub
ssh -vT [email protected]
# Test connection to GitLab
ssh -vT [email protected]
# Test connection to Bitbucket
ssh -vT [email protected]Look for output like:
debug1: Offering public key: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering public key: /home/user/.ssh/id_ed25519
debug1: Authentications that can continue: publickey
...
Received disconnect from 192.30.255.112: Too many authentication failuresThis shows SSH trying multiple keys. If the correct key isn't early in the list, you'll hit the server's limit.
List keys in your agent:
ssh-add -lThis shows all keys currently loaded, often more than you expect.
The recommended solution is to configure SSH to use only the correct key for each Git host. Edit (or create) your ~/.ssh/config file.
Open or create the config file:
# Create the file if it doesn't exist
touch ~/.ssh/config
chmod 600 ~/.ssh/config
# Edit the file
nano ~/.ssh/config
# or: vim ~/.ssh/config
# or: code ~/.ssh/configAdd entries for each Git host:
# GitHub
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/github_key
IdentitiesOnly yes
# GitLab
Host gitlab.com
HostName gitlab.com
User git
IdentityFile ~/.ssh/gitlab_key
IdentitiesOnly yes
# Bitbucket
Host bitbucket.org
HostName bitbucket.org
User git
IdentityFile ~/.ssh/bitbucket_key
IdentitiesOnly yes
# Work GitHub Enterprise
Host github.mycompany.com
HostName github.mycompany.com
User git
IdentityFile ~/.ssh/work_key
IdentitiesOnly yesKey settings explained:
- IdentityFile: The specific key to use (no other keys will be tried first)
- IdentitiesOnly yes: Tells SSH to ONLY use the specified key, ignoring ssh-agent
Test your configuration:
ssh -T [email protected]
# Expected: "Hi username! You've successfully authenticated..."If configuring SSH config isn't an option, you can manage which keys are loaded in your ssh-agent.
Remove all keys from the agent:
ssh-add -DAdd only the key you need:
# Add a specific key
ssh-add ~/.ssh/github_key
# Verify only that key is loaded
ssh-add -lTest the connection:
ssh -T [email protected]Note: This is a temporary solution. Keys may be reloaded automatically on system restart or by your desktop environment. The SSH config approach (Step 2) is more permanent.
If using macOS Keychain:
# Remove all keys from agent and keychain
ssh-add -D
ssh-add -K # (deprecated, use --apple-use-keychain in newer macOS)
# Add just the key you need to the keychain
ssh-add --apple-use-keychain ~/.ssh/github_keyFor quick troubleshooting or one-time operations, you can specify the key directly in the SSH command.
Clone with a specific key:
GIT_SSH_COMMAND="ssh -i ~/.ssh/github_key -o IdentitiesOnly=yes" git clone [email protected]:user/repo.gitSet for the current repository:
# Inside a repository, set the SSH command for that repo only
git config core.sshCommand "ssh -i ~/.ssh/github_key -o IdentitiesOnly=yes"Set globally (affects all repositories):
git config --global core.sshCommand "ssh -i ~/.ssh/default_key -o IdentitiesOnly=yes"Alternative: Use the GIT_SSH_COMMAND environment variable:
export GIT_SSH_COMMAND="ssh -i ~/.ssh/github_key -o IdentitiesOnly=yes"
git pullThis approach is useful when you can't modify ~/.ssh/config (e.g., on shared systems).
If you have multiple accounts on the same service (e.g., personal and work GitHub accounts), use SSH config aliases.
Configure multiple GitHub accounts:
# Personal GitHub
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/personal_github
IdentitiesOnly yes
# Work GitHub (same host, different key)
Host github-work
HostName github.com
User git
IdentityFile ~/.ssh/work_github
IdentitiesOnly yesClone using the alias:
# Personal account
git clone [email protected]:personal/repo.git
# Work account (note the alias)
git clone git@github-work:company/repo.gitUpdate existing repository remotes:
# View current remote
git remote -v
# Change to use the alias
git remote set-url origin git@github-work:company/repo.gitThis lets you seamlessly switch between accounts without modifying SSH agent or environment variables.
If previous authentication failures triggered security software, your IP might be temporarily blocked.
Symptoms of IP blocking:
- SSH connections fail immediately or timeout
- Error persists even after fixing your SSH config
- Other users on different IPs can connect fine
- The error started after multiple failed attempts
If you control the server:
# Check if fail2ban blocked you
sudo fail2ban-client status sshd
# Unban an IP
sudo fail2ban-client set sshd unbanip YOUR_IP_ADDRESS
# Check /etc/hosts.deny for DenyHosts
sudo cat /etc/hosts.deny | grep YOUR_IP
# Remove the line if found
sudo nano /etc/hosts.denyIf you don't control the server (GitHub, GitLab, etc.):
- Wait 15-30 minutes for temporary blocks to expire
- Try from a different network (mobile hotspot, VPN)
- Contact the service's support if blocks persist
Prevention:
- Always use IdentitiesOnly yes in SSH config
- Don't leave many keys loaded in ssh-agent
- Test SSH config changes with verbose mode first
SSH is strict about file permissions. Incorrect permissions can cause keys to be ignored or connections to fail.
Check and fix key permissions:
# Private keys must be readable only by you
chmod 600 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_ed25519
chmod 600 ~/.ssh/github_key
# Public keys can be less restrictive
chmod 644 ~/.ssh/id_rsa.pub
chmod 644 ~/.ssh/id_ed25519.pub
# SSH config file
chmod 600 ~/.ssh/config
# .ssh directory itself
chmod 700 ~/.sshCheck key format:
# View the key type and fingerprint
ssh-keygen -l -f ~/.ssh/github_key
# Verify the public key matches what's on GitHub/GitLab
cat ~/.ssh/github_key.pub
# Compare with: GitHub > Settings > SSH and GPG keysIf using older RSA keys:
Some servers may reject older RSA keys or require specific algorithms:
# Generate a new ed25519 key (more secure, widely supported)
ssh-keygen -t ed25519 -C "[email protected]"
# Or an RSA key with SHA-256
ssh-keygen -t rsa -b 4096 -C "[email protected]"Remember to add the new public key to your Git hosting service.
Understanding MaxAuthTries:
The SSH server setting MaxAuthTries (default: 6) limits authentication attempts per connection. Each key offered by ssh-agent counts as one attempt. If you have 10 keys loaded and the correct one is 7th, you'll hit the limit before SSH tries it.
The Authentication Flow:
1. SSH client connects to server
2. ssh-agent offers keys one by one
3. Server responds "try again" for wrong keys
4. After MaxAuthTries failures, server disconnects
5. Error: "Too many authentication failures"
Why ssh-agent Offers All Keys:
By default, ssh-agent tries to be helpful by offering every loaded key. This design assumes most users have few keys. The IdentitiesOnly yes directive changes this behavior, restricting SSH to only try explicitly specified keys.
Git-Specific Configurations:
Git 2.10+ supports core.sshCommand for per-repository SSH settings:
# Per-repo configuration
git config core.sshCommand "ssh -i ~/.ssh/work_key -o IdentitiesOnly=yes"
# Check the current setting
git config --get core.sshCommandFor older Git versions, use the GIT_SSH_COMMAND environment variable or configure SSH through ~/.ssh/config.
SSH Agent Forwarding Considerations:
When using SSH agent forwarding (ssh -A), all keys from your local agent are available on the remote server. This can compound the "too many keys" problem:
Host bastion
ForwardAgent yes
IdentityFile ~/.ssh/bastion_key
IdentitiesOnly yes # Important!Without IdentitiesOnly, forwarding adds your local keys to the remote's authentication attempts.
Windows-Specific Notes:
Git for Windows:
- Uses its own SSH by default (C:\Program Files\Git\usr\bin\ssh.exe)
- Config file location: C:\Users\YourName\.ssh\config
- Use forward slashes in paths even on Windows
Configure Git to use Windows OpenSSH:
git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"Using Pageant (PuTTY agent):
Pageant loads all keys at startup. Be selective about which keys you add.
IDE and GUI Tool Considerations:
Many IDEs manage their own SSH connections:
- VS Code: Uses system SSH config
- JetBrains IDEs: Can use built-in SSH or system SSH
- GitHub Desktop: Uses its own credential management
Ensure your SSH config is correct, as IDEs typically respect ~/.ssh/config.
Enterprise Proxy and Jump Host Scenarios:
For complex network setups with jump hosts:
Host github.com
ProxyJump bastion.company.com
IdentityFile ~/.ssh/github_key
IdentitiesOnly yes
Host bastion.company.com
IdentityFile ~/.ssh/bastion_key
IdentitiesOnly yesDebugging SSH Connections:
# Maximum verbosity
ssh -vvv [email protected]
# Check which config file is being used
ssh -G [email protected] | grep -i identitySecurity Considerations:
- Don't disable IdentitiesOnly globally; configure per-host
- Rotate SSH keys periodically
- Use passphrase-protected keys
- Consider hardware security keys (FIDO2/U2F) for high-security scenarios
- Audit which keys are deployed to which services
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server
fatal: unable to access: Proxy auto-configuration failed
How to fix 'Proxy auto-configuration failed' in Git
fatal: unable to access: Authentication failed (proxy requires basic auth)
How to fix 'Authentication failed (proxy requires basic auth)' in Git
fatal: unable to access: no_proxy configuration not working
How to fix 'no_proxy configuration not working' in Git
fatal: unable to read tree object in treeless clone
How to fix 'unable to read tree object in treeless clone' in Git