How to fix Received disconnect from host: Too many authentication failures in Git

GitINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 208 views

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
  1. Diagnose the issue with verbose SSH output
  2. Configure SSH to use the correct key for each host
  3. Clear and selectively reload SSH agent keys
  4. Use command-line options for one-off connections
git — error
# 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
Received 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

  1. Multiple SSH keys loaded in ssh-agent are tried before the correct one
  2. No SSH config specifying which key to use for each host
  3. ssh-agent automatically offers all loaded keys to every server
  4. The correct key is loaded but tried after too many incorrect keys
  5. SSH server's MaxAuthTries limit is set lower than the number of keys you have
  6. IDE or Git GUI tools use different SSH agent settings
  7. Recent system or SSH configuration changes added new keys to the agent
  8. fail2ban or DenyHosts on the server has blocked your IP after previous failures

How to fix "Received disconnect from host: Too many authentication failures"

1Diagnose the issue with verbose SSH output

First, identify which keys SSH is offering and in what order. This helps you understand why authentication is failing.

Run SSH with verbose output:

bash
# 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

Look for output like:

bash
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 failures

This 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:

bash
ssh-add -l

This shows all keys currently loaded, often more than you expect.

2Configure SSH to use the correct key for each host

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:

bash
# 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/config

Add entries for each Git host:

bash
# 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 yes

Key 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:

bash
ssh -T git@github.com
# Expected: "Hi username! You've successfully authenticated..."
3Clear and selectively reload SSH agent keys

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:

bash
ssh-add -D

Add only the key you need:

bash
# Add a specific key
ssh-add ~/.ssh/github_key

# Verify only that key is loaded
ssh-add -l

Test the connection:

bash
ssh -T git@github.com

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:

bash
# 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_key
4Use command-line options for one-off connections

For quick troubleshooting or one-time operations, you can specify the key directly in the SSH command.

Clone with a specific key:

bash
GIT_SSH_COMMAND="ssh -i ~/.ssh/github_key -o IdentitiesOnly=yes" git clone git@github.com:user/repo.git

Set for the current repository:

bash
# 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):

bash
git config --global core.sshCommand "ssh -i ~/.ssh/default_key -o IdentitiesOnly=yes"

Alternative: Use the GIT_SSH_COMMAND environment variable:

bash
export GIT_SSH_COMMAND="ssh -i ~/.ssh/github_key -o IdentitiesOnly=yes"
git pull

This approach is useful when you can't modify ~/.ssh/config (e.g., on shared systems).

5Handle multiple accounts on the same host

If you have multiple accounts on the same service (e.g., personal and work GitHub accounts), use SSH config aliases.

Configure multiple GitHub accounts:

bash
# 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 yes

Clone using the alias:

bash
# Personal account
git clone git@github.com:personal/repo.git

# Work account (note the alias)
git clone git@github-work:company/repo.git

Update existing repository remotes:

bash
# View current remote
git remote -v

# Change to use the alias
git remote set-url origin git@github-work:company/repo.git

This lets you seamlessly switch between accounts without modifying SSH agent or environment variables.

6Check for IP blocks from fail2ban or DenyHosts

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:

bash
# 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.deny

If 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

7Verify key permissions and formats

SSH is strict about file permissions. Incorrect permissions can cause keys to be ignored or connections to fail.

Check and fix key permissions:

bash
# 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 ~/.ssh

Check key format:

bash
# 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 keys

If using older RSA keys:
Some servers may reject older RSA keys or require specific algorithms:

bash
# 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:

bash
# Per-repo configuration
git config core.sshCommand "ssh -i ~/.ssh/work_key -o IdentitiesOnly=yes"

# Check the current setting
git config --get core.sshCommand

For 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:

bash
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:

bash
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:

bash
Host github.com
    ProxyJump bastion.company.com
    IdentityFile ~/.ssh/github_key
    IdentitiesOnly yes

Host bastion.company.com
    IdentityFile ~/.ssh/bastion_key
    IdentitiesOnly yes

Debugging SSH Connections:

bash
# Maximum verbosity
ssh -vvv git@github.com

# Check which config file is being used
ssh -G git@github.com | grep -i identity

Security 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