Corrigindo "Host key verification failed"

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

O Que Significa "Host key verification failed"?

Conclusão: A chave do host apresentada pelo servidor não corresponde à que seu cliente lembra, então a conexão foi abortada. Não é um problema de chave ou senha — a verificação para na identidade do servidor.

Antes de o SSH autenticar você (por senha ou chave pública), ele primeiro verifica se o servidor que você alcançou é genuíno. Ele faz isso com a "chave do host" do servidor, que é registrada em ~/.ssh/known_hosts na primeira conexão. Em cada conexão posterior, se a chave apresentada não corresponder ao registro, o SSH aborta. Isso é 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 (reconstrução de servidor, IP reutilizado, raramente um ataque man-in-the-middle)
• Um host de primeira vez foi rejeitado pela verificação estrita (StrictHostKeyChecking yes etc.)

As correções são completamente diferentes, então identifique qual caso você tem primeiro.

Como Fazer a Triagem da Causa?

Conclusão: Leia a linha logo acima do erro. REMOTE HOST IDENTIFICATION HAS CHANGED significa divergência de chave; No ... host key is known significa que um host de primeira vez foi rejeitado.

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

Padrão A: a chave mudou (divergência 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.

Padrão 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 Padrão A vá para Corrigindo uma chave alterada; para o Padrão B vá para Conexões de primeira vez.

Por Que a Chave Muda? Visão Geral

Conclusão: A maioria das mudanças são eventos legítimos do lado do servidor (reconstrução, IP reutilizado). Uma pequena fração são man-in-the-middle, então sempre confirme que a mudança é legítima antes de excluir.

A maioria dos casos é de baixo risco, mas quando a chave muda sem explicação, não pule a verificação antes de excluir.

Onde Fica o known_hosts e o Que Ele Registra?

Conclusão: Registros por usuário ficam em ~/.ssh/known_hosts, os do sistema em /etc/ssh/ssh_known_hosts. Cada linha é "host/IP + tipo de chave + chave pública", e a divergência 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 não padrão são 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)

Conclusão: Remova a entrada com ssh-keygen -R hostname, depois reconecte e registre a nova chave. Você não precisa abrir known_hosts e excluir a linha manualmente.

O erro imprime o arquivo e número da linha: Offending ... key in /home/user/.ssh/known_hosts:12. Remover isso é a correção, mas ssh-keygen -R é mais seguro do que editar manualmente pelo número 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 você usa uma porta não padrão, use o formato registrado.

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

Se você também conecta por IP, deve remover tanto a entrada do hostname quanto a do IP.

$ ssh-keygen -R 192.0.2.10

Após 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 Mudança é Legítima

Conclusão: Se a mudança é inesperada, compare com a fingerprint real do servidor antes de excluir. Se diferirem, suspeite de man-in-the-middle e não conecte por esse caminho.

O propósito inteiro de Host key verification failed é detectar personificação. O hábito de limpar o aviso mecanicamente desativa essa proteção você mesmo.

Se você consegue acessar o servidor por outro caminho (console, etc.), exiba a fingerprint da própria 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 à fingerprint que o SSH mostra ao reconectar, a mudança é legítima e você pode registrá-la com segurança. Se diferir, desconfie desse caminho de conexão.

Conexões de Primeira Vez (StrictHostKeyChecking)

Conclusão: No ... host key is known ... strict checking significa que StrictHostKeyChecking yes rejeitou um host desconhecido. Registre a chave correta com segurança; não afrouxe para no.

Para um servidor de primeira vez com verificação 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 correção é registrar a chave correta em known_hosts. A forma mais segura é registrá-la após 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 mantém a detecção de personificação.

Pré-Registrando known_hosts (ssh-keyscan)

Conclusão: Para automação ou implantações em frota, ssh-keyscan pode buscar chaves e adicioná-las ao known_hosts — mas apenas quando você confia no próprio caminho de busca.

Para CI / Ansible onde nenhum prompt interativo é possível, registre chaves antes de conectar.

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

Você também pode buscar vários hosts de uma vez.

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

Checklist Quando Ainda Falha

Conclusão: 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 configurações demais.

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