Como corrigir Too many authentication failures no SSH

O que significa "Too many authentication failures"

"Too many authentication failures" significa que o cliente SSH ofereceu ao servidor mais chaves do que ele estava disposto a verificar, e o servidor encerrou a ligação antes de a chave correta ser testada. Isto é quase sempre um problema no cliente. A chave está no seu disco, o servidor tem essa chave em authorized_keys, mas nenhum desses factos ajuda, porque a ligação terminou demasiado cedo.

A sequência é esta. ssh-agent contém todas as chaves privadas que carregou. O cliente oferece essas chaves ao servidor uma de cada vez, porque não tem como saber qual delas é aceite pela conta. O servidor rejeita cada chave que não esteja em authorized_keys e conta cada rejeição como uma tentativa de autenticação falhada. MaxAuthTries em sshd_config limita o número de falhas permitidas numa ligação. O valor predefinido é 6. Se o seu agente tiver dez chaves e a correta for a oitava da sequência, o servidor encerra a ligação antes de chegar a ela.

Por isso, a correção consiste em fazer o cliente oferecer uma única chave: a correta.

O que o servidor contabiliza e onde entra MaxAuthTries

A autenticação por chave pública começa como um processo de tentativas. O cliente envia uma chave pública e pergunta se o servidor aceitaria uma assinatura feita com ela. O servidor responde sim ou não. Um “não” é uma tentativa falhada, exatamente como uma palavra-passe incorreta.

A página de manual sshd_config(5) descreve o limite: “Especifica o número máximo de tentativas de autenticação permitidas por ligação. Quando o número de falhas atinge metade deste valor, as falhas adicionais são registadas. O valor predefinido é 6.”

Seis tentativas são suficientes para uma pessoa que introduz uma palavra-passe. Não são muitas para um agente que tem dez chaves. Quando o número de falhas ultrapassa o limite, o sshd termina a ligação e escreve uma linha semelhante no log do sistema:

error: maximum authentication attempts exceeded for deploy from 203.0.113.10 port 51292 ssh2

O cliente apresenta a outra metade do mesmo evento:

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

Esta é uma falha diferente de erro de permissão negada do SSH (publickey). Nesse caso, o servidor analisou tudo o que foi oferecido e não aceitou nada. Aqui, o servidor deixou de analisar as opções. Confundir os dois casos leva a passar uma tarde a copiar novamente uma chave que já estava correta.

Por que a mesma chave funciona no portátil do seu colega

Não há qualquer diferença na chave nem no servidor. O agente dele tem duas chaves, enquanto o seu tem doze. A chave que chega primeiro para ele é a nona para você. Nessa altura, a ligação já terminou.

A quantidade aumenta silenciosamente. AddKeysToAgent yes em ~/.ssh/config adiciona cada chave que você usa ao agente e mantém-na lá. Agentes de chaveiros de ambiente de trabalho, como o GNOME Keyring no Linux ou o chaveiro de início de sessão no macOS, carregam as chaves no início de sessão sem pedir confirmação. Adicione uma chave de cliente, uma chave de um servidor Git e uma chave de uma máquina de laboratório ao longo de um ano. Um dia, um servidor que sempre funcionou começa a recusá-lo. Nada mudou no servidor. O seu agente ficou mais cheio.

Como ver as ofertas com ssh -v

Execute a ligação que falha com -v e leia o rastreio.

ssh -v deploy@203.0.113.10

Há dois tipos de linha relevantes. Will attempt key: lista as identidades que o cliente reuniu, pela ordem em que as utilizará. Offering public key: aparece uma vez para cada chave efetivamente enviada para o servidor.

debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Will attempt key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent

Os seus caminhos, tipos de chave e fingerprints serão diferentes. Conte o número de linhas Offering public key: antes da desligação. Se as ofertas avançarem e a sessão terminar sem que a chave pretendida apareça, o diagnóstico está confirmado. A palavra agent no fim de uma linha significa que essa identidade veio de ssh-agent. A palavra explicit significa que veio de uma linha IdentityFile ou de -i na linha de comandos.

Em seguida, consulte o que o agente tem carregado:

ssh-add -l

Cada linha da saída corresponde a uma chave carregada. Se for apresentada The agent has no identities., o agente não é a causa do problema. Nesse caso, consulte as linhas IdentityFile em ~/.ssh/config. Se for apresentada Could not open a connection to your authentication agent., não há nenhum agente em execução e as ofertas estão a ser obtidas dos seus ficheiros de chave predefinidos.

Correção 1: IdentitiesOnly com uma chave por host

IdentitiesOnly yes faz o ssh oferecer apenas as identidades que configurou e ignorar as restantes que o agente disponibiliza. Combine-a com uma linha IdentityFile, e o cliente enviará uma única oferta.

Host vps
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519_vps
  IdentitiesOnly yes

Guarde isso em ~/.ssh/config e execute chmod 600 ~/.ssh/config. Um ficheiro com permissões de escrita para o grupo ou para qualquer utilizador faz o ssh recusar-se a executar, com Bad owner or permissions on /home/you/.ssh/config. Agora ssh vps oferece uma chave, e ssh -v vps deverá mostrar exatamente uma linha Offering public key:.

Há dois detalhes que surpreendem muitos utilizadores.

• IdentitiesOnly yes, por si só, não significa "uma chave". Os ficheiros de identidade predefinidos contam como identidades configuradas, por isso o ssh continua a tentar ~/.ssh/id_ed25519, ~/.ssh/id_rsa e os restantes ficheiros predefinidos que encontrar. Também precisa da linha IdentityFile.
• O agente continua a fazer a assinatura. IdentitiesOnly controla quais chaves são oferecidas, não quem faz a assinatura. Se a chave privada indicada por IdentityFile estiver carregada no agente, o agente produzirá a assinatura e nunca lhe será pedida uma frase-passe. Também pode apontar IdentityFile para o ficheiro .pub correspondente. É isso que deve fazer quando a chave privada existe apenas no agente ou num token de hardware.

Uma armadilha em ~/.ssh/config desfaz esta correção silenciosamente. A maioria das palavras-chave usa o primeiro valor encontrado, razão pela qual os blocos Host específicos devem ficar acima de Host *. IdentityFile não segue essa regra. O manual diz: "É possível especificar vários ficheiros de identidade nos ficheiros de configuração; todas essas identidades serão tentadas em sequência." Um IdentityFile dentro de Host * é adicionado ao definido por host, em vez de o substituir. Assim, uma linha global esquecida volta a adicionar uma oferta a todas as ligações.

Se quiser uma rede de segurança global, defina apenas a flag no fim do ficheiro:

Host *
  IdentitiesOnly yes

Cada host precisará então da sua própria IdentityFile, que é precisamente o resultado pretendido. Nomear uma chave por servidor também permite revogar posteriormente o acesso de uma única máquina sem emitir tudo de novo. Vale a pena criar esse hábito desde cedo: consulte como gerir chaves SSH por máquina.

Correção 2: limpar ou reiniciar o agent

Se ainda não pode editar a configuração, limpe o agent e carregue apenas o que precisa.

ssh-add -l                    # list what is loaded
ssh-add -d ~/.ssh/id_rsa      # remove one key
ssh-add -D                    # remove every key
ssh-add ~/.ssh/id_ed25519_vps # load the one you need

Se a ligação funcionar logo depois de ssh-add -D, o agent era a causa. Considere isto um teste, não uma correção. Um agent de keyring do ambiente de trabalho recarrega as chaves no próximo início de sessão, por isso o problema volta amanhã. Uma linha IdentitiesOnly em ~/.ssh/config persiste depois de um reboot. Um agent vazio não.

Também pode definir um tempo de vida para uma chave, para que o agent a remova automaticamente:

ssh-add -t 1800 ~/.ssh/id_ed25519_vps

A chave é removida 1800 segundos depois de ser adicionada. Reiniciar o agent também funciona, mas o procedimento depende do que o iniciou. Um ssh-agent iniciado manualmente é parado com ssh-agent -k. Se o executar a partir de uma unidade de utilizador do systemd que criou, reinicie essa unidade com systemctl --user restart <unit>. Um agent de keyring reinicia com a sessão do ambiente de trabalho.

Correção 3: o comando único para um servidor que será acedido uma vez

Para um host que não será adicionado à sua configuração, coloque as mesmas definições na linha de comandos:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10

-i sozinho é a correção errada mais comum. -i adiciona uma chave à lista de identidades. Não remove as chaves do agente dessa lista. Por isso, todas as outras chaves continuam a ser oferecidas antes da sua e a ligação continua a falhar ao atingir o limite. Execute ssh -v -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10 sem IdentitiesOnly e verá as chaves do agente serem oferecidas primeiro. -i precisa de -o IdentitiesOnly=yes junto dele.

Para retirar completamente o agente da ligação:

ssh -o IdentityAgent=none -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10

Depois, o ssh lê a chave privada do disco e pede a respetiva frase-passe, caso exista.

As ferramentas baseadas em ssh aceitam a mesma opção:

scp -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps report.tar.gz deploy@203.0.113.10:/tmp/
rsync -av -e "ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" ./site/ deploy@203.0.113.10:/srv/site/
GIT_SSH_COMMAND="ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" git clone git@example.com:team/repo.git

Por que o erro aparece no segundo salto

Com ForwardAgent yes, o socket do agente fica disponível no servidor ao qual se liga. Um comando ssh executado nesse servidor usa o agente local, com todas as suas chaves, através do socket encaminhado. Por isso, o erro pode aparecer no salto de um jump host para o servidor final, embora o primeiro salto tenha funcionado corretamente. Execute echo $SSH_AUTH_SOCK na máquina intermédia: um caminho de socket indica que há um agente encaminhado acessível; uma saída vazia indica que não há nenhum.

O encaminhamento do agente tem um segundo risco. Qualquer pessoa com root nessa máquina intermédia pode usar o seu agente para se autenticar como você enquanto a sessão estiver aberta. ProxyJump evita ambos os problemas:

ssh -J deploy@jump.example.com deploy@10.0.0.5

ProxyJump abre uma ligação através do jump host e autentica-se no servidor final a partir da sua própria máquina. Assim, o seu ~/.ssh/config local aplica-se em todos os saltos, incluindo IdentitiesOnly. Desativar ForwardAgent é uma medida padrão ao reforçar a segurança do SSH num VPS.

É recomendável aumentar MaxAuthTries no servidor?

Normalmente, não. Verifique primeiro o valor atual:

sudo sshd -T | grep -i maxauthtries

sshd -T apresenta a configuração efetiva, incluindo os valores predefinidos. Assim, mostra o valor real mesmo quando sshd_config não o define. Adicione -C user=deploy,host=example.com,addr=203.0.113.10 se utilizar blocos Match, porque estes são avaliados por ligação e, caso contrário, são ignorados.

Aumentar o limite funciona, no sentido restrito de dar a um cliente com comportamento incorreto mais tentativas:

MaxAuthTries 20

Valide o ficheiro e recarregue o serviço. Mantenha uma segunda sessão aberta enquanto faz isso:

sudo sshd -t
sudo systemctl reload ssh      # Debian and Ubuntu
sudo systemctl reload sshd     # RHEL family

Se systemctl is-enabled ssh.socket apresentar enabled no Ubuntu 24.04, o sshd é ativado por socket. É iniciado um processo novo para cada ligação, que lê sshd_config novamente. Por isso, as novas ligações aplicam a alteração automaticamente.

Agora analise o efeito da alteração. O cliente está a oferecer chaves que este servidor nunca aceitará. Aumentar o limite permite que o servidor processe vinte ofertas rejeitadas por ligação, em vez de seis, para cada cliente que se ligue e para cada tentativa de adivinhar palavras-passe na Internet. Cada oferta obriga o servidor a consultar authorized_keys. O seu início de sessão continua lento, porque a chave correta permanece no fim da lista. Se adicionar uma décima terceira chave ao seu agente, volta ao problema inicial e terá de pedir novamente um número maior.

Aumente o limite apenas quando um cliente legítimo precisar realmente de apresentar várias identidades. Em todos os outros casos, corrija o cliente. Reduzir o limite é uma medida de reforço razoável depois de todos os utilizadores iniciarem sessão com uma chave configurada, porque um número menor dá menos tentativas por ligação a quem tenta adivinhar credenciais.

Por que o fail2ban pode bloquear o seu endereço neste caso

No nível de log predefinido, o sshd regista cada chave pública rejeitada:

Failed publickey for deploy from 203.0.113.10 port 51292 ssh2: ED25519 SHA256:AAAA...

Uma ligação de um agente completo produz várias dessas linhas a partir do mesmo endereço num ou dois segundos. A jail sshd do fail2ban conta as linhas de falha do sshd e bloqueia o endereço de origem quando maxretry é atingido dentro de findtime. Esses intervalos são pequenos por predefinição, por isso duas tentativas de uma ligação com problemas podem ser suficientes para bloquear o seu próprio endereço.

O sintoma muda, e é esta parte que causa confusão. Deixa de ver "Too many authentication failures" e passa a não ver nada: a ligação fica pendurada e acaba por exceder o tempo limite, porque a firewall está agora a descartar os seus pacotes em vez de responder. Um timeout onde antes recebia uma mensagem de erro é o sinal, e essa distinção é explicada em ligação SSH recusada versus ligação SSH que excede o tempo limite.

A partir da consola do seu provedor, ou de um endereço diferente, verifique a jail e remova o bloqueio:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 203.0.113.10

Coloque o seu próprio endereço em ignoreip dentro de jail.local enquanto corrige o cliente e remova-o quando terminar. A própria jail é configurada no guia do fail2ban para Ubuntu 24.04.

What to do once, so this stops coming back

Give every server its own Host block in ~/.ssh/config, with HostName, User, IdentityFile and IdentitiesOnly yes. After that, ssh vps is short to type, it offers exactly one key, and it cannot trip MaxAuthTries however full your agent becomes. It also keeps ssh -v output short enough to read on the day something else breaks.

FAQ

Como corrijo imediatamente "Too many authentication failures"?

Ofereça apenas uma chave, em vez de todas. Para uma ligação imediata, execute ssh -o IdentitiesOnly=yes -i ~/.ssh/your_key user@host. Para uma correção permanente, adicione um bloco a ~/.ssh/config com HostName, User e IdentityFile apontados para essa chave, e IdentitiesOnly yes; depois execute chmod 600 ~/.ssh/config. Confirme com ssh -v: deve ver uma linha Offering public key: para esse host.

Por que ssh -i continua a oferecer as minhas outras chaves?

Porque -i adiciona uma identidade à lista, mas não restringe a lista. As chaves carregadas em ssh-agent continuam na lista e também são oferecidas, muitas vezes antes da sua. Por isso, o servidor pode atingir MaxAuthTries antes de chegar à sua chave. -o IdentitiesOnly=yes é a opção que limita o ssh às identidades indicadas. Use -i e -o IdentitiesOnly=yes em conjunto, ou -o IdentityAgent=none para ignorar completamente o agente nessa ligação.

Devo aumentar MaxAuthTries no servidor para corrigir isto?

Não, em quase todos os casos. O cliente está a enviar chaves que o servidor nunca aceitará. Um limite maior apenas faz o servidor avaliar mais ofertas rejeitadas por ligação, para todos os clientes e todas as tentativas de brute force que o alcancem. O problema também volta a ocorrer assim que outra chave é carregada no agente. Consulte o valor efetivo com sudo sshd -T | grep -i maxauthtries, se quiser, e corrija o cliente com IdentitiesOnly.

Por que isto começou num servidor que funcionava bem no mês passado?

O seu agente ficou com mais chaves. AddKeysToAgent yes em ~/.ssh/config mantém carregada cada chave que utiliza, e os agentes do keyring do ambiente de trabalho carregam chaves automaticamente durante o login. Quando o número de chaves carregadas ultrapassa MaxAuthTries no servidor, qualquer servidor cuja chave esteja no fim da ordem de ofertas começa a falhar. Execute ssh-add -l e compare a quantidade com o limite configurado no servidor.

Isto pode fazer com que o fail2ban bloqueie o meu endereço IP?

Sim. Cada chave rejeitada produz uma linha Failed publickey for ... no log do servidor. Assim, uma ligação pode gerar várias falhas a partir do seu endereço em poucos segundos, e a jail sshd do fail2ban bloqueia o endereço quando maxretry é atingido dentro de findtime. O sinal é que o erro muda para uma espera prolongada e depois para um timeout, porque os pacotes estão a ser descartados em vez de receberem resposta. Remova o bloqueio a partir da consola com sudo fail2ban-client set sshd unbanip <your address> e corrija o cliente antes de voltar a ligar-se.