Corrigindo "Too many authentication failures"

2026-06-06 Tempo de leitura: Cerca de 11 min Dificuldade: Intermediário

O que está acontecendo com "Too many authentication failures"?

Conclusão: O servidor atingiu o número permitido de tentativas de autenticação (MaxAuthTries, padrão 6) antes de alcançar sua chave correta. A chave não está errada -- você simplesmente está oferecendo muitas.

A conexão SSH em si teve sucesso e seu cliente está se comunicando com o sshd do servidor. Isso não é um problema de rede nem uma chave inválida.

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures
Disconnected from 203.0.113.10 port 22

O sshd limita o número de tentativas de autenticação por conexão (MaxAuthTries, padrão 6). Com autenticação por chave pública, cada chave que o cliente oferece conta como uma tentativa. Se seu ssh-agent tem muitas chaves, o ssh as oferece em ordem independentemente de o servidor aceitá-las, e atinge o limite antes de chegar na correta.

O que verificar primeiro?

Conclusão: Execute ssh -v e conte as linhas Offering public key:. Quantas chaves você oferece antes da desconexão é a evidência direta da causa.

O primeiro passo é tornar visível quantas chaves você está enviando.

$ ssh -v user@server.example.com

Linhas para observar:

debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:...
debug1: Offering public key: ssh-ed25519 SHA256:... agent
debug1: Offering public key: ssh-rsa SHA256:... agent
...
Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

Se cerca de seis linhas Offering public key se alinham e a conexão cai logo depois, a causa está confirmada: você oferece muitas chaves e esgota MaxAuthTries antes de enviar a correta.

Por que oferecer muitas chaves é rejeitado?

Conclusão: O sshd limita tentativas por conexão a MaxAuthTries. Cada chave pública consome uma tentativa apenas por ser oferecida, então com muitas chaves o orçamento se esgota antes da chave correta ser tentada.

O mecanismo, passo a passo:

1. O cliente oferece suas chaves disponíveis ao servidor em ordem.
2. O servidor verifica se a chave oferecida está em authorized_keys; se não, diz "próxima".
3. Cada ida e volta conta como uma tentativa.
4. Quando as tentativas atingem MaxAuthTries, o servidor desconecta sem esperar um sucesso.

Então, se você tem dez chaves e a correta é a nona, você é cortado na sexta e nunca a alcança. É isso que "too many" significa.

Qual é a correção rápida para conectar agora?

Conclusão: Combine -o IdentitiesOnly=yes com -i key para oferecer exatamente uma chave. Isso mantém as tentativas em uma e você entra imediatamente.

$ ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@server.example.com

IdentitiesOnly=yes é a parte crucial. Sem ele, mesmo quando você especifica uma chave com -i, o ssh também oferece as chaves no ssh-agent, então o número de tentativas não diminui. Esta é a maior armadilha aqui.

Se você não tem certeza de qual chave é a correta, adicione -v e tente uma por vez.

$ ssh -v -o IdentitiesOnly=yes -i ~/.ssh/id_rsa user@server.example.com

Se você ver Authentication succeeded (publickey), essa chave é a correta. Torne permanente com o próximo passo.

Como corrigir permanentemente no ~/.ssh/config?

Conclusão: Defina IdentityFile e IdentitiesOnly yes por host no ~/.ssh/config. A partir de então, a chave é limitada a uma automaticamente, sem opções de linha de comando.

Host myserver
    HostName server.example.com
    User user
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Agora ssh myserver sozinho conecta oferecendo apenas a chave especificada.

Se você gerencia vários servidores, dê a cada host seu próprio bloco.

Host prod
    HostName prod.example.com
    User deploy
    IdentityFile ~/.ssh/id_prod
    IdentitiesOnly yes

Host gitlab
    HostName gitlab.example.com
    User git
    IdentityFile ~/.ssh/id_gitlab
    IdentitiesOnly yes

Como limpar chaves do ssh-agent?

Conclusão: Verifique a contagem com ssh-add -l; se houver muitas, limpe com ssh-add -D e re-adicione apenas o que você precisa. Um agent inchado é a causa raiz comum de "oferecendo muitas".

Primeiro, verifique o estado atual.

$ ssh-add -l

256 SHA256:... user@host (ED25519)
3072 SHA256:... old-key (RSA)
256 SHA256:... another (ED25519)
...

Se seis ou mais estão listadas, elas consomem o orçamento de tentativas em todo servidor a menos que você use IdentitiesOnly. Remova as que você não precisa.

# Limpar tudo e re-adicionar
$ ssh-add -D
$ ssh-add ~/.ssh/id_ed25519

Para remover uma chave específica apenas:

$ ssh-add -d ~/.ssh/id_rsa

Deve-se ajustar MaxAuthTries no servidor?

Conclusão: Se você administra o servidor, aumentar MaxAuthTries contorna o problema, mas é um paliativo que enfraquece a resistência à força bruta. A correção adequada é limitar as chaves no cliente.

Verifique o valor efetivo com sshd -T.

$ sudo sshd -T | grep -i maxauthtries

maxauthtries 6

Somente quando uma operação realmente não pode evitar oferecer muitas chaves, aumente o valor em /etc/ssh/sshd_config.

MaxAuthTries 10

$ sudo systemctl reload ssh

Checklist para prevenir recorrência

Conclusão: "Oferecer exatamente uma chave" é a essência da correção. Configure IdentitiesOnly no seu config, organize o agent e confirme a configuração do servidor um por um, e não se repetirá.

• [ ] O ssh -v mostra mais linhas Offering public key do que MaxAuthTries (padrão 6)?
• [ ] A correção rápida -o IdentitiesOnly=yes -i key permite conectar?
• [ ] Você adicionou IdentityFile e IdentitiesOnly yes ao Host alvo no ~/.ssh/config?
• [ ] Há muitas chaves em ssh-add -l (limpe com ssh-add -D se sim)?
• [ ] Se chaves reaparecem automaticamente, você verificou AddKeysToAgent e scripts de inicialização?
• [ ] Como administrador do servidor, você confirmou o maxauthtries efetivo com sshd -T?