Corrigindo "Host key verification failed"

2026-06-05 Tempo de leitura: Cerca de 11 min Dificuldade: Intermediario

O Que Significa "Host key verification failed"?

Conclusao: A chave do host apresentada pelo servidor nao corresponde a que seu cliente lembra, entao a conexao foi abortada. Nao e um problema de chave ou senha — a verificacao para na identidade do servidor.

Antes de o SSH autenticar voce (por senha ou chave publica), ele primeiro verifica se o servidor que voce alcancou e genuino. Ele faz isso com a "chave do host" do servidor, que e registrada em ~/.ssh/known_hosts na primeira conexao. Em cada conexao posterior, se a chave apresentada nao corresponder ao registro, o SSH aborta. Isso e Host key verification failed.

Host key verification failed.

O ponto importante: este erro tem duas causas distintas.

• Uma chave diferente foi apresentada do que a registrada (reconstrucao de servidor, IP reutilizado, raramente um ataque man-in-the-middle)
• Um host de primeira vez foi rejeitado pela verificacao estrita (StrictHostKeyChecking yes etc.)

As correcoes sao completamente diferentes, entao identifique qual caso voce tem primeiro.

Como Fazer a Triagem da Causa?

Conclusao: Leia a linha logo acima do erro. REMOTE HOST IDENTIFICATION HAS CHANGED significa divergencia de chave; No ... host key is known significa que um host de primeira vez foi rejeitado.

A causa esta impressa na linha logo antes de Host key verification failed.. Role para cima e leia.

Padrao A: a chave mudou (divergencia com o registro)

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
...
Offending ECDSA key in /home/user/.ssh/known_hosts:12
...
Host key verification failed.

Padrao B: um host de primeira vez foi rejeitado

No ED25519 host key is known for server.example.com and you have requested strict checking.
Host key verification failed.

Para o Padrao A va para Corrigindo uma chave alterada; para o Padrao B va para Conexoes de primeira vez.

Por Que a Chave Muda? Visao Geral

Conclusao: A maioria das mudancas sao eventos legitimos do lado do servidor (reconstrucao, IP reutilizado). Uma pequena fracao sao man-in-the-middle, entao sempre confirme que a mudanca e legitima antes de excluir.

A maioria dos casos e de baixo risco, mas quando a chave muda sem explicacao, nao pule a verificacao antes de excluir.

Onde Fica o known_hosts e o Que Ele Registra?

Conclusao: Registros por usuario ficam em ~/.ssh/known_hosts, os do sistema em /etc/ssh/ssh_known_hosts. Cada linha e "host/IP + tipo de chave + chave publica", e a divergencia com ele dispara este erro.

$ cat ~/.ssh/known_hosts

Uma linha mapeia para uma chave de um host.

server.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA...
[server.example.com]:2222 ecdsa-sha2-nistp256 AAAAE2VjZHNh...

Note que portas nao padrao sao registradas como [hostname]:port. Para encontrar a entrada correspondente, use ssh-keygen -F.

$ ssh-keygen -F server.example.com

Corrigindo uma Chave Alterada (ssh-keygen -R)

Conclusao: Remova a entrada com ssh-keygen -R hostname, depois reconecte e registre a nova chave. Voce nao precisa abrir known_hosts e excluir a linha manualmente.

O erro imprime o arquivo e numero da linha: Offending ... key in /home/user/.ssh/known_hosts:12. Remover isso e a correcao, mas ssh-keygen -R e mais seguro do que editar manualmente pelo numero da linha.

$ ssh-keygen -R server.example.com

# Host server.example.com found: line 12
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old

Se voce usa uma porta nao padrao, use o formato registrado.

$ ssh-keygen -R '[server.example.com]:2222'

Se voce tambem conecta por IP, deve remover tanto a entrada do hostname quanto a do IP.

$ ssh-keygen -R 192.0.2.10

Apos excluir, reconectar solicita sobre a nova chave. Verifique a fingerprint e confirme com yes.

$ ssh user@server.example.com

The authenticity of host 'server.example.com (192.0.2.10)' can't be established.
ED25519 key fingerprint is SHA256:abcd1234...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Antes de Excluir: Confirme Que a Mudanca e Legitima

Conclusao: Se a mudanca e inesperada, compare com a fingerprint real do servidor antes de excluir. Se diferirem, suspeite de man-in-the-middle e nao conecte por esse caminho.

O proposito inteiro de Host key verification failed e detectar personificacao. O habito de limpar o aviso mecanicamente desativa essa protecao voce mesmo.

Se voce consegue acessar o servidor por outro caminho (console, etc.), exiba a fingerprint da propria chave do host do servidor.

$ ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

256 SHA256:abcd1234... root@server (ED25519)

Se este SHA256:... corresponder a fingerprint que o SSH mostra ao reconectar, a mudanca e legitima e voce pode registra-la com seguranca. Se diferir, desconfie desse caminho de conexao.

Conexoes de Primeira Vez (StrictHostKeyChecking)

Conclusao: No ... host key is known ... strict checking significa que StrictHostKeyChecking yes rejeitou um host desconhecido. Registre a chave correta com seguranca; nao afrouxe para no.

Para um servidor de primeira vez com verificacao estrita habilitada, o SSH recusa imediatamente sem prompt interativo.

No ED25519 host key is known for server.example.com and you have requested strict checking.
Host key verification failed.

A correcao e registrar a chave correta em known_hosts. A forma mais segura e registra-la apos verificar a fingerprint real do servidor. Para permitir apenas desta vez, use accept-new.

$ ssh -o StrictHostKeyChecking=accept-new user@server.example.com

accept-new (OpenSSH 7.6+) registra automaticamente hosts desconhecidos mas ainda rejeita uma chave alterada para um host conhecido, diferente de no. Ele automatiza apenas o registro de primeira vez enquanto mantem a deteccao de personificacao.

Pre-Registrando known_hosts (ssh-keyscan)

Conclusao: Para automacao ou implantacoes em frota, ssh-keyscan pode buscar chaves e adiciona-las ao known_hosts — mas apenas quando voce confia no proprio caminho de busca.

Para CI / Ansible onde nenhum prompt interativo e possivel, registre chaves antes de conectar.

$ ssh-keyscan -t ed25519 server.example.com >> ~/.ssh/known_hosts

Voce tambem pode buscar varios hosts de uma vez.

$ ssh-keyscan server1 server2 server3 >> ~/.ssh/known_hosts

Checklist Quando Ainda Falha

Conclusao: Diferencie A de B pela linha acima do erro — corrija A com ssh-keygen -R, corrija B com registro seguro. Sempre verifique antes de excluir e evite afrouxar as configuracoes demais.

• [ ] Voce leu a linha logo acima de Host key verification failed. (A: mudanca / B: primeira vez)?
• [ ] Para o Padrao A, voce verificou o arquivo e linha em Offending ... known_hosts:NN?
• [ ] A mudanca de chave e esperada? (Se nao, compare fingerprints.)
• [ ] Voce removeu com ssh-keygen -R hostname (incluindo formato de porta e IP)?
• [ ] A fingerprint ao reconectar correspondeu ao valor conhecido como correto?
• [ ] Para o Padrao B, voce evitou configurar descuidadamente StrictHostKeyChecking no? (Considere accept-new.)
• [ ] Ha entradas obsoletas no /etc/ssh/ssh_known_hosts do sistema?