Aviso: a identificação do host remoto mudou e como corrigi-la

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

Muitos desses erros tornaram-se bem conhecidos na comunidade SSH e suas soluções alternativas estão amplamente documentadas. Estes incluem incompatibilidade de firewall, Problemas de injeção de chave pública SSH, Problemas no modo de chave de arquivo 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 origem do problema pode ser uma preocupação legítima de segurança, e não uma simples falha técnica. Neste artigo, explicaremos por que isso acontece, o que isso significa para a segurança da sua conexão SSH e como resolver isso em cada plataforma principal.

O que desencadeia o aviso: a identificação do host remoto mudou (e você deve se preocupar?)

O “Aviso: a identificação do host remoto foi alterada” aparece quando a chave pública SSH armazenada em seu hosts_conhecidos arquivo não corresponde à chave que o servidor está apresentando atualmente. Essa incompatibilidade aciona o mecanismo de segurança integrado do SSH para protegê-lo contra ameaças potenciais.

Razões legítimas para alterações na chave do host

Várias razões inocentes explicam por que a chave de host de um servidor pode mudar. Às vezes, você verá variações como “A chave do host RSA foi alterada”, dependendo do tipo de chave específico que está sendo usado.

Infográfico mostrando alterações de servidor que modificam chaves de host SSH, incluindo atualizações de sistema operacional, recriações de servidor, restauração de backup, migração física para virtual e redefinições de configuração SSH.
Mudanças relacionadas ao servidor:

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

Alterações na configuração da rede:

Os provedores de nuvem reciclam endereços IP ao longo do tempo ou suas rotas de conexão por meio de um balanceador de carga.
DHCP reatribuiu um endereço IP para uma máquina diferente
O IP de um servidor desativado foi atribuído a um novo sistema
Os 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 a desativação e reemissão do servidor causando conflitos de chave de host SSH.

Principais Ações de Gestão:

Os administradores do sistema regeneraram manualmente as chaves do host para fins de segurança
O software do servidor SSH foi reinstalado
As políticas de segurança exigiam rotação de chaves

É importante reconhecer que as alterações na senha do usuário não afetam as chaves do host. Estes representam mecanismos de autenticação separados. As chaves do 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 genuína à segurança. Você deve se preocupar se:

Você não fez nenhuma alteração no servidor nem sabe de nenhuma manutenção programada
Você não pode verificar o motivo da alteração da chave com o administrador do servidor
O servidor é acessado por redes públicas ou conexões não confiáveis
Você está se conectando a sistemas de produção ou servidores que contêm dados confidenciais

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

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

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

Como verificar se o aviso é seguro

Antes de prosseguir para corrigir o problema, siga estas etapas de verificação:

Fluxograma mostrando cinco métodos de verificação para confirmar alterações legítimas de chaves de host SSH, incluindo consulta à equipe, contato com o provedor de hospedagem, canais seguros e comparação de impressões digitais.

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

Se você puder confirmar que a alteração da chave foi legítima, poderá prosseguir com segurança com a remoção da chave antiga e a aceitação da nova.

Se você quiser evitar a reatribuição dinâmica de IP ou conflitos de chave de host, a infraestrutura escolhida desempenha um papel importante.

Cloudzy fornece Hospedagem VPS SSH com IPs estáticos dedicados. Você roda em processadores AMD Ryzen 9 com armazenamento NVMe para execução instantânea de comandos. Nossa rede atinge 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 “A identificação do host remoto foi alterada”

A correção é simples: remova o registro de chave antigo do seu sistema. Isso elimina a incompatibilidade e permite salvar a nova chave na próxima vez que você se conectar. Confira nosso guia em Clientes SSH para mais ferramentas.

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

Método 1: a linha de comando (mais rápido)

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

Abra seu terminal.
Execute este comando (substitua nome do host com o 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ê mesmo pode excluir a chave. A mensagem de erro geralmente informa 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. Exclua-o e pressione Ctrl + X e Y para salvar.

Janela do terminal do macOS mostrando o editor de texto nano aberto com o arquivoknown_hosts, destacando a linha para excluir com etapas numeradas e instruções para salvar exibidas.

Solução para Windows

Os usuários do Windows normalmente 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 em Configurações > Aplicativos > Recursos opcionais. O Server 2025 inclui o cliente, mas você deve ativá-lo.

Se você usar o PowerShell ou o prompt de comando, o ssh-keygen O comando do Método 1 também funciona aqui.

Para editar o arquivo manualmente:

Imprensa Tecla Windows + R.
Tipo %USERPROFILE%\.ssh e pressione Digitar.
Abra o hosts_conhecidos arquivo com o Bloco de Notas.
Exclua a linha que está causando o erro e salve o arquivo.

Para gerenciar chaves corretamente, consulte nosso guia em gerando 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, tipo regedite bateu Digitar).
Navegue para: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
Encontre a entrada que corresponde ao nome de host ou IP do seu servidor.
Clique com o botão direito e selecione Excluir.

Comando do Windows PowerShell removendo a chave do host SSH com o File Explorer mostrando o arquivoknown_hosts atualizado e o PuTTY Registry Editor exibindo a caixa de diálogo de confirmação de exclusão da chave do host.

Solução para Linux

O ssh-keygen comando que abordamos Método 1 é a maneira padrão de corrigir isso no Linux. É rápido e tem suporte nativo.

Edição manual

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

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

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

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 de arquivos conhecidos_hosts.
Um aviso sobre a desativação de verificações

Você pode forçar a conexão do SSH sem verificação, mas isso é arriscado. Ele ignora a proteção contra ataques man-in-the-middle.

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

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

Se você estiver no Windows, o caminho Unix falhará. Você deve usar NUL para fazer o bypass funcionar:

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

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

Corrigir incompatibilidades de chaves é uma manutenção de rotina, mas você pode fazer mais para proteger sua conexão. Os bots geralmente têm como alvo a porta 22 padrão com ataques de força bruta. Você pode evitar a maior parte desse ruído de fundo alterando portas SSH no Linux para algo menos previsível.

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

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

Como evitar que a mensagem “A identificação do host remoto foi alterada” na próxima vez

Embora nem sempre seja possível evitar alterações legítimas nas chaves do host, você pode minimizar as interrupções e manter melhores práticas de segurança.

Guia de referência rápida

Seu papel	Estratégias-chave
Administradores de sistema	Faça backup de chaves, documente alterações, use certificados e alterne chaves regularmente
Usuários regulares	Mantenha o inventário, verifique através de canais seguros e monitore os registros
Ambiente em nuvem Usuários	Use nomes DNS, aproveite as ferramentas do provedor e implemente a infraestrutura como código

Infográfico mostrando as melhores práticas 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ões.

Para administradores de sistema

Faça backup das chaves do host: Salvar chaves de /etc/ssh/ antes de reinstalar o sistema operacional. Restaure-os posteriormente para evitar avisos para seus usuários.

Documentar alterações planejadas: Alerte 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 de certificação central. Isso assina chaves de host e elimina a necessidade de verificação manual.

Implementar rotação de chave: Agende as alterações da chave do host. Atualizações previsíveis são mais fáceis de serem gerenciadas pela sua equipe do que atualizações surpresa.

Para usuários regulares

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

Verifique via fora de banda: Confirme as chaves em uma fonte confiável, como o console da nuvem, e não em mensagens casuais.

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

Use o 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-se usando nomes de host em vez de IPs. Isso mantém a consistência quando o endereço subjacente é alterado.

Aproveite as ferramentas da nuvem: Use consoles de provedores para recuperar impressões digitais atuais. Verifique as chaves nessas ferramentas antes de aceitar as alterações.

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

Hostes Bastiões: Configure servidores de salto com chaves estáveis. Eles atuam como pontos de entrada seguros para sua infraestrutura dinâmica.

Conclusão

O “Aviso: a identificação do host remoto foi alterada” serve como um importante recurso de segurança do SSH, não uma falha a ser ignorada. Embora esse aviso geralmente apareça por motivos legítimos, como manutenção do servidor ou alterações de configuração, ele desempenha um papel fundamental na proteção contra ataques man-in-the-middle e acesso não autorizado.

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

Ao aprender como funcionam as chaves de host SSH e seguir as práticas recomendadas, você pode manter a segurança e a conveniência em seus fluxos de trabalho de acesso remoto. Para obter mais informações sobre como transferir arquivos com segurança, consulte copiando arquivos via SSH.

Perguntas frequentes

Devo levar em conta o aviso: a identificação remota do host mudou seriamente?

Sim, leve isso a sério. Isso significa que a identidade do servidor foi alterada, o que pode sinalizar um ataque man-in-the-middle ou apenas uma manutenção de rotina. Sempre verifique a alteração com seu administrador ou provedor antes de aceitar a nova chave para garantir a segurança.

O que causa o aviso: a identificação do host remoto foi alterada?

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

Este erro pode acontecer em diferentes sistemas operacionais?

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

Como posso saber se a alteração da chave do host é legítima ou um ataque?

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

Desativar a verificação da chave do host tornará o SSH mais conveniente?

Acrescenta 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ê só deve usar essa configuração em ambientes de teste isolados, nunca em servidores de produção ou redes públicas que envolvam dados confidenciais.

Com que frequência as chaves do host SSH devem ser alteradas?

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

Aviso: a identificação do host remoto foi alterada e como corrigi-la