Aviso: Remote Host Identification Has Changed & Como Corrigir

SSH é um protocolo de rede seguro que cria um túnel criptografado entre sistemas. Continua popular entre desenvolvedores que precisam de acesso remoto a computadores sem precisar de uma interface gráfica. Embora SSH exista há décadas e tenha servido inúmeros usuários de forma confiável, ainda pode ser afetado por certos erros.

Muitos desses erros se tornaram bem conhecidos na comunidade SSH, e suas soluções são amplamente documentadas. Eles incluem incompatibilidade de firewall, Problemas de injeção de chave pública em SSH, Problemas de modo de chave de arquivo em SSHe o erro 'Aviso: A Identificação do Host Remoto Foi Alterada'.

Este erro ocorre em todos os principais sistemas operacionais, incluindo Windows, Linux e macOS. A fonte do problema pode ser uma preocupação legítima de segurança em vez de uma simples falha técnica. Neste artigo, explicaremos por que isso acontece, o que significa para a segurança de sua conexão SSH e como resolvê-lo em cada plataforma principal.

O que Causa o Aviso: A Identificação do Host Remoto Foi Alterada (e Você Deve Se Preocupar?)

O aviso 'A Identificação do Host Remoto Foi Alterada' aparece quando a chave pública SSH armazenada no seu known_hosts arquivo não corresponde à chave que o servidor está apresentando no momento. Esta incompatibilidade dispara o mecanismo de segurança integrado do SSH para protegê-lo de possíveis ameaças.

Razões Legítimas para Alterações de Chave de Host

Várias razões inofensivas explicam por que a chave de host de um servidor pode mudar. Às vezes você verá variações como 'Chave de host RSA foi alterada', dependendo do tipo de chave específica que está sendo usada.

Infográfico mostrando alterações de servidor que modificam as chaves de host SSH, incluindo atualizações do SO, reconstruções de servidor, restauração de backup, migração física para virtual e redefinições de configuração SSH.
Alterações Relacionadas ao Servidor:

O sistema operacional do servidor foi reinstalado ou atualizado
O servidor foi reconstruído ou restaurado a partir de um backup
A configuração SSH do servidor foi redefinida
A máquina física ou virtual foi substituída
Migração do servidor para novo hardware

Alterações de Configuração de Rede:

Provedores de nuvem reciclam endereços IP ao longo do tempo, ou sua conexão passa através de um balanceador de carga.
DHCP reatribuiu um endereço IP a uma máquina diferente
O IP de um servidor desativado foi atribuído a um novo sistema
Registros DNS foram atualizados para apontar para um servidor diferente

Diagrama de rede mostrando um servidor DHCP atribuindo endereços IP dinâmicos a máquinas virtuais, com desativação e reatribuição de servidor causando conflitos de chave de host SSH.

Ações de Gerenciamento de Chaves:

Administradores do sistema regeneraram manualmente as chaves de host para fins de segurança
O software servidor SSH foi reinstalado
Políticas de segurança exigiram rotação de chaves

É importante reconhecer que alterações de senha do usuário não afetam as chaves de host. Elas representam mecanismos de autenticação separados. As chaves de host mudam apenas quando o próprio servidor ou sua configuração SSH é modificada.

Quando Levar o Aviso a Sério

Embora muitas alterações de chave de host sejam legítimas, isso pode indicar uma ameaça de segurança genuína. Você deve se preocupar se:

Você não fez alterações no servidor ou não conhece nenhuma manutenção programada
Você não consegue verificar o motivo da alteração de chave com o administrador do servidor
O servidor é acessado através de redes públicas ou conexões não confiáveis
Você está se conectando a sistemas de produção ou servidores contendo dados sensíveis

Tela dividida comparando alterações legítimas de SSH mostradas em verde com cenários de ameaça de segurança em vermelho, apresentando uma figura encapuzada representando ataques man-in-the-middle.
Ataques intermediário, embora relativamente raros, ocorrem. Neles, um invasor se posiciona entre seu computador e o servidor legítimo, interceptando todo o tráfego.

Erro humano e engenharia social representam 68% das violações de segurança, o que torna a vigilância essencial. Você pode proteger seus sistemas ainda mais aprendendo sobre prevenção de ataques de força bruta.

Estatísticas recentes da IBM mostram que o custo global médio de uma vazamento de dados foi de US$ 4,44 milhões em 2025, com tempo médio de detecção de oito meses. Isso explica por que o mecanismo de verificação de chave do host SSH existe e por que você nunca deve ignorar esses avisos sem investigação.

Como Verificar se o Aviso é Seguro

Antes de prosseguir para corrigir o problema, execute essas etapas de verificação:

Fluxograma mostrando cinco métodos de verificação para confirmar mudanças legítimas de chave do host SSH, incluindo consulta com a equipe, contato com o provedor de hospedagem, canais seguros e comparação de impressão digital.

Consulte sua equipe: Se você compartilha acesso ao servidor, pergunte aos colegas se fizeram alterações
Revise os registros do servidor: Verifique registros de manutenção ou logs de alterações para atividade recente
Entre em contato com seu provedor de hospedagem: Se estiver usando serviços em nuvem, verifique se houve manutenção
Use um canal seguro: Se possível, conecte-se por uma rede segura conhecida para verificar a impressão digital
Comparar impressões digitais: Alguns provedores de hospedagem exibem as impressões digitais atuais do SSH em seus painéis de controle

Se conseguir confirmar que a mudança de chave foi legítima, pode prosseguir com segurança removendo a chave antiga e aceitando a nova.

Se quiser evitar reatribuição dinâmica de IP ou conflitos de chave do host, a infraestrutura que você escolhe faz uma grande diferença.

Cloudzy fornece Hospedagem SSH VPS com IPs estáticos dedicados. Você executa em processadores AMD Ryzen 9 com armazenamento NVMe para execução instantânea de comandos. Nossa rede alcança 40 Gbps em 12 locais globais. Além disso, incluímos proteção DDoS gratuita para manter sua conexão segura.

Como Corrigir o Erro "Remote Host Identification Has Changed"

A solução é simples: remova o registro de chave antiga do seu sistema. Isso elimina o conflito e permite que você salve a nova chave na próxima conexão. Confira nosso guia sobre Clientes SSH para mais ferramentas.

Além disso, você pode fazer isso com um único comando ou editando o arquivo manualmente.

Método 1: Linha de Comando (Mais Rápido)

Este método funciona para macOS, Linux e Windows 10+ (usando OpenSSH). É a forma mais rápida de resolver o erro. Para mais informações, consulte a página do manual ssh-keygen.

Abra seu terminal.
Execute este comando (substitua hostname pelo IP ou domínio do seu servidor):

ssh-keygen -R hostname

This command automatically finds the old key in your known_hosts file and deletes it.  Method 2: Manual File Editing (macOS)

Se preferir um editor visual, você pode deletar a chave manualmente. A mensagem de erro geralmente indica exatamente qual número de linha remover.

Abra seu terminal e edite o arquivo com Nano:

nano ~/.ssh/known_hosts

Encontre a linha da sua mensagem de erro. Delete-a e pressione Ctrl + X e Y para guardar.

Janela do terminal macOS mostrando o editor de texto nano aberto com o arquivo known_hosts, destacando a linha a deletar com passos numerados e instruções de salvamento exibidas.

Solução para Windows

Usuários de Windows geralmente usam o cliente OpenSSH integrado ou PuTTY.

Opção 1: Windows OpenSSH (Windows 10/11)

No Windows 10 e 11, OpenSSH é um recurso opcional. Adicione-o através de Configurações > Aplicativos > Recursos opcionais. O Server 2025 inclui o cliente, mas você deve ativá-lo.

Se usar PowerShell ou Prompt de Comando, o ssh-keygen comando do Método 1 funciona aqui também.

Para editar o arquivo manualmente:

Pressione Tecla Windows + R.
Tipo %USERPROFILE%\.ssh e pressione Enter.
Abrir o known_hosts arquivo com o Bloco de Notas.
Delete a linha causando o erro e salve o arquivo.

Para gerenciar chaves corretamente, consulte nosso guia sobre geração de chaves SSH no Windows.

Opção 2: Usando PuTTY

PuTTY armazena chaves no Registro do Windows em vez de um arquivo.

Abra o Editor do Registro (Pressione Tecla Windows + R, digitar regedit, e clique Enter).
Navegue para: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
Procure a entrada que corresponde ao nome de host ou IP do seu servidor.
Clique com o botão direito e selecione Excluir.

Comando PowerShell Windows removendo a chave de host SSH com o Explorador de Arquivos mostrando o arquivo known_hosts atualizado, e o Editor de Registro do PuTTY exibindo o diálogo de confirmação de exclusão da chave de host.

Solução para Linux

O ssh-keygen comando que abordamos em Método 1 é a forma padrão de resolver isso em Linux. É rápido e suportado nativamente.

Edição Manual

Se preferir visualizar o conteúdo do arquivo, pode editá-lo com um editor de texto como Nano.

Abra seu terminal.
Tipo nano ~/.ssh/known_hosts e pressione Enter.
Localize o número de linha mencionado na sua mensagem de erro.
Exclua a linha e pressione Ctrl + X e Y para guardar.

Você também pode usar Vim (vim ~/.ssh/known_hosts) se estiver familiarizado com isso.

Terminal Linux mostrando comandos ssh-keygen para remover chaves de host SSH por nome de host e endereço IP, com confirmação de sucesso e exemplos do arquivo known_hosts.
Um Aviso Sobre Desabilitar Verificações

Você pode forçar SSH a se conectar sem verificação, mas isso é arriscado. Isso contorna a proteção contra ataques man-in-the-middle.

Use esta abordagem apenas para testes locais em redes confiáveis. Para macOS e Linux, digite:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected]

Se você está em Windows, o caminho Unix falha. Você deve usar NUL para que a contornada funcione:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL [email protected]

Não execute essas substituições em conexões públicas ou servidores em produção.

Corrigir incompatibilidades de chaves é manutenção de rotina, mas você pode fazer mais para proteger sua conexão. Bots frequentemente direcionam a porta padrão 22 com ataques de força bruta. Você pode evitar a maioria desse ruído de fundo alterando as portas SSH em Linux para algo menos previsível.

Diagrama de um ataque man-in-the-middle em SSH: invasor interceptando a conexão cliente-servidor, chave do invasor versus chave do servidor, roubo de dados e perda financeira destacados.

Nunca use este método para servidores em produção ou em redes não confiáveis.

Como Prevenir a Mensagem "Remote Host Identification Has Changed" da Próxima Vez

Embora você nem sempre consiga prevenir mudanças legítimas de chave de host, pode minimizar interrupções e manter práticas de segurança melhores.

Guia de Referência Rápida

Seu Papel	Estratégias Principais
Administradores de Sistema	Faça backup de chaves, documente alterações, use certificados e rotacione chaves regularmente
Usuários Comuns	Mantenha um inventário, verifique através de canais seguros e monitore logs
Ambiente em Nuvem Utilizadores	Use nomes DNS, aproveite ferramentas do provedor e implemente infraestrutura como código

Infográfico mostrando práticas recomendadas de gerenciamento de chaves SSH: use certificados SSH, nomes DNS, infraestrutura como código, faça backup de chaves de host, documente alterações e considere hosts bastião.

Para Administradores de Sistema

Faça Backup das Chaves de Host: Salve as chaves de /etc/ssh/ antes de reinstalar o SO. Restaure-as depois para evitar avisos aos seus usuários.

Documente Alterações Planejadas: Notifique os usuários antes de alterar as chaves e compartilhe as novas impressões digitais com segurança. Isso permite que eles verifiquem a conexão.

Use Certificados SSH: Equipes grandes devem usar uma autoridade certificadora central. Ela assina as chaves de host e elimina a necessidade de verificação manual.

Implemente Rotação de Chaves: Agende as mudanças de chaves de host. Atualizações previsíveis são mais fáceis de gerenciar pela sua equipe do que atualizações inesperadas.

Para Usuários Comuns

Manter um Inventário: Mantenha um registro pessoal de impressões digitais de servidor ou use a documentação segura da sua equipe.

Verifique por Canal Alternativo: Confirme as chaves em relação a uma fonte confiável como o console da nuvem, não em mensagens casuais.

Monitorar Logs: Verifique seus logs SSH locais regularmente para padrões de conexão estranhos ou erros repetidos.

Use Gerenciamento de Configuração: Use arquivos de configuração SSH para lidar com ambientes de desenvolvimento dinâmicos sem reduzir as configurações de segurança.

Para Ambientes de Nuvem Dinâmicos

Use Nomes DNS: Conecte usando nomes de host em vez de IPs. Isso mantém a consistência quando o endereço subjacente muda.

Aproveite Ferramentas de Nuvem: Use os consoles do provedor para recuperar impressões digitais atuais. Verifique as chaves em relação a essas ferramentas antes de aceitar mudanças.

Infraestrutura como Código: Automatize a verificação de chaves com ferramentas como Terraform. Para configurações avançadas, você também pode usar proxies SSH SOCKS5.

Hosts Bastion: Configure servidores de salto com chaves estáveis. Eles funcionam como pontos de entrada seguros para sua infraestrutura dinâmica.

Conclusão

O aviso "Warning: Remote Host Identification Has Changed" funciona como uma ferramenta importante de segurança do SSH, não um defeito a ser ignorado. Embora esse aviso apareça frequentemente por motivos legítimos, como manutenção do servidor ou mudanças de configuração, ele desempenha um papel fundamental na proteção contra ataques man-in-the-middle e acessos não autorizados.

Quando você encontrar esse aviso, verifique a causa antes de prosseguir. Na maioria dos casos, a solução é direta: remova a chave de host antiga usando os métodos descritos para seu sistema operacional e aceite a nova chave na próxima conexão.

Ao aprender como as chaves de host do SSH funcionam e seguir as melhores práticas, você consegue manter segurança e conveniência em seus fluxos de trabalho de acesso remoto. Para mais informações sobre transferência segura de arquivos, consulte cópia de arquivos via SSH.

Perguntas Frequentes

Devo Levar o Aviso "Remote Host Identification Has Changed" a Sério?

Sim, leve a sério. Significa que a identidade do servidor mudou, o que pode indicar um ataque man-in-the-middle ou apenas manutenção de rotina. Sempre verifique a mudança com seu administrador ou provedor antes de aceitar a nova chave para garantir segurança.

O Que Causa o Aviso "Remote Host Identification Has Changed"?

Esse aviso ocorre quando a impressão digital atual do servidor não corresponde à que está em seu arquivo known_hosts. As causas comuns incluem reinstalações do sistema operacional, realocações de IP ou redefinições de configuração do SSH. Em casos raros, indica uma interceptação ativa de ataque man-in-the-middle.

Esse Erro Pode Acontecer em Diferentes Sistemas Operacionais?

Sim, esse aviso afeta todos os sistemas operacionais que usam SSH, incluindo Windows, macOS e Linux. Ele decorre da verificação de segurança do protocolo SSH. Embora os métodos de correção variem por plataforma, o gatilho de segurança subjacente permanece idêntico em todos os sistemas.

Como Saber se a Mudança de Chave de Host é Legítima ou um Ataque?

Para confirmar a legitimidade, verifique se houve manutenção recente, atualizações de sistema operacional ou mudanças de IP. Você precisa verificar a nova impressão digital em uma fonte confiável, como o console do seu provedor de nuvem ou uma confirmação do seu administrador de sistemas, antes de se conectar.

Desabilitar a Verificação de Chave de Host Tornará o SSH Mais Conveniente?

Adiciona conveniência, mas remove segurança. Desabilitar as verificações elimina a proteção contra ataques man-in-the-middle, deixando as conexões vulneráveis. Você deve usar essa configuração apenas em ambientes de teste isolados, nunca em servidores de produção ou redes públicas com dados sensíveis.

Com Que Frequência as Chaves de Host do SSH Devem Ser Alteradas?

As chaves de host geralmente não exigem rotação regular. Você deve alterá-las apenas após uma reconstrução de servidor, reinstalação do sistema operacional ou comprometimento de segurança. Mudanças frequentes prejudicam os usuários, então priorize a estabilidade e uma comunicação clara quando as atualizações forem necessárias.

Aviso: Identificação do Host Remoto Foi Alterada e Como Corrigir