How to fix Received disconnect from host: Too many authentication failures in Git
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.
Quick fix
Fixes Received disconnect from host: Too many authentication failures
# Test connection to GitHub
ssh -vT git@github.com
# Test connection to GitLab
ssh -vT git@gitlab.com
# Test connection to Bitbucket
ssh -vT git@bitbucket.org- Diagnose the issue with verbose SSH output
- Configure SSH to use the correct key for each host
- Clear and selectively reload SSH agent keys
- Use command-line options for one-off connections
# Test connection to GitHubssh -vT git@github.com# Test connection to GitLabssh -vT git@gitlab.com# Test connection to Bitbucketssh -vT git@bitbucket.orgReceived disconnect from host: Too many authentication failures
What this error means
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.
Typical symptoms
- Git push, pull, fetch, or clone operations fail with 'Too many authentication failures'
- SSH connection to Git hosting services disconnects immediately
- The error appears after adding new SSH keys to your system
- Git operations work with one account but fail with another
- Adding the -v flag to ssh shows multiple keys being offered and rejected
- Git operations over HTTPS work fine, but SSH connections fail
- The error occurs inconsistently, sometimes working and sometimes failing
Common causes
- Multiple SSH keys loaded in ssh-agent are tried before the correct one
- No SSH config specifying which key to use for each host
- ssh-agent automatically offers all loaded keys to every server
- The correct key is loaded but tried after too many incorrect keys
- SSH server's MaxAuthTries limit is set lower than the number of keys you have
- IDE or Git GUI tools use different SSH agent settings
- Recent system or SSH configuration changes added new keys to the agent
- fail2ban or DenyHosts on the server has blocked your IP after previous failures
How to fix "Received disconnect from host: Too many authentication failures"
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 git@github.com
# Test connection to GitLab
ssh -vT git@gitlab.com
# Test connection to Bitbucket
ssh -vT git@bitbucket.orgLook 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 git@github.com
# 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 git@github.comNote: 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 git@github.com: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 git@github.com: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 "your_email@example.com"
# Or an RSA key with SHA-256
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"Remember to add the new public key to your Git hosting service.
Advanced notes
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 git@github.com
# Check which config file is being used
ssh -G git@github.com | 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
Frequently asked questions
- What does "Received disconnect from host: Too many authentication failures" mean?
- 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.
- How do I fix "Received disconnect from host: Too many authentication failures"?
- 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.
- What causes "Received disconnect from host: Too many authentication failures"?
- Multiple SSH keys loaded in ssh-agent are tried before the correct one No SSH config specifying which key to use for each host ssh-agent automatically offers all loaded keys to every server
- Is the "Received disconnect from host: Too many authentication failures" error serious?
- It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.
Official resources & further reading
- 📚Git Official Documentation
- 💬SSH: too many authentication failures - Stack Overflow(Stack Overflow)
- 📖
- 💬
- 📖
- 💬
- 💬