Os avisos "Host key verification failed" e "REMOTE HOST IDENTIFICATION HAS CHANGED" do SSH

O que é

A página de manual ssh(1) documenta que o cliente compara a chave de host apresentada pelo servidor com a entrada guardada para esse host em known_hosts. Se não existe entrada e a verificação estrita está ativada, ou se o prompt de confirmação não pode ser exibido (BatchMode=yes, ausência de terminal, como na maioria das automações), o cliente aborta com Host key verification failed.. Se existe uma entrada, mas a chave apresentada é diferente, o ssh primeiro exibe um aviso grande e difícil de ignorar, que inclui WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! e uma linha sobre um possível ataque man-in-the-middle, indica o arquivo e a linha exatos onde está a entrada antiga e, por fim, termina com o mesmo Host key verification failed..

Por que importa

A mesma mensagem é produzida tanto por um ataque real de substituição de chave quanto por vários eventos totalmente comuns: um servidor recriado ou reinstalado do zero, um IP flutuante ou load balancer que passou a apontar para outro host, ou uma máquina reprovisionada a partir de uma imagem que gera novas chaves de host no primeiro boot. O texto do aviso, por si só, não permite distinguir um ataque de uma mudança rotineira na infraestrutura, e é justamente por isso que não é seguro descartá-lo por reflexo.

Como aplicar

• Diagnostique antes de alterar qualquer coisa: avalie se o host poderia legitimamente ter uma nova chave. Ele foi recriado, migrado ou reapontado recentemente? Compare as datas com as mudanças de infraestrutura conhecidas.
• Verifique por outro canal: obtenha a impressão digital (fingerprint) da nova chave por um meio que não seja a própria conexão SSH, como o responsável pelo servidor, um recurso do console do provedor de nuvem que permita consultar a chave do host, ou um valor registrado pela ferramenta de gerenciamento de configuração durante o provisionamento, e compare-a com a que o ssh informa para a chave recém-oferecida antes de prosseguir.
• Somente depois de confirmar que a nova chave é legítima: remova a entrada obsoleta com ssh-keygen -R hostname, que o ssh-keygen(1) documenta como a remoção de todas as chaves pertencentes ao host indicado em um arquivo known_hosts (para uma porta não padrão, a entrada é '[hostname]:2222'; um endereço IP também pode ter a sua própria entrada). Depois conecte-se novamente e aceite a nova chave.
• Prática insegura: definir rotineiramente ssh -o StrictHostKeyChecking=no, ou contornar o prompt por script, como configuração permanente. Isso elimina justamente a proteção destinada a detectar uma substituição real de chave e, se for usado, deve ficar restrito a hosts realmente descartáveis em uma rede isolada, em que o risco foi aceito de forma explícita, e não como solução geral para evitar o incômodo. Para o primeiro contato em automações, StrictHostKeyChecking=accept-new (OpenSSH 7.6+) registra hosts desconhecidos, mas continua recusando chaves alteradas; melhor ainda é preencher previamente o known_hosts com chaves verificadas.

Armadilhas

• Tratar toda ocorrência como rotina porque "normalmente é" no seu ambiente; esse hábito é exatamente aquilo com que conta um atacante que aposta em que esse aviso seja ignorado.
• Apagar o arquivo known_hosts inteiro para "começar do zero", em vez de remover apenas a linha problemática, o que descarta a verificação de todos os outros hosts em que você já confiava.