A resposta curta
Existe um arquivo que foi alterado desde a última vez que você tentou acessar o servidor SSH em execução nesse host. Esse arquivo é
/Users/whateveryourusernameis/.ssh/known_hosts
Em algum lugar desse arquivo existe uma entrada, apenas uma linha, começando com o host que você tentou acessar entre colchetes como [vpsXXX.ovh.net] .
Se tiver certeza de que o servidor que você está tentando acessar é aquele que você acabou de alterar e configurar sozinho, é seguro remover essa linha e tentar novamente.
A resposta mais longa, telefonada em
O SSH é a ferramenta mais básica no cinturão do administrador, e como funciona merece sua atenção.
Quando você entra em contato com um servidor ssh, um dos primeiros passos do servidor é apresentar ao cliente ssh a sua própria chave de host pública. Essa chave é normalmente anexada ao arquivo ~/.ssh/known_hosts do cliente, de modo que, se essa chave for alterada entre diferentes sessões ssh, o cliente será avisado de que o host não é mais o host original que contatou antes. Isso alerta você para o fato de que o host que você acessou possivelmente é um impostor, a menos que você já saiba, sem dúvida, que o host mudou, de fato.
A chave do host é uma parte central do processo de negociação do SSH , com o qual você deve se familiarizar se estiver administrando qualquer sistema. Esta chave é normalmente gerada apenas uma vez, a primeira vez que um servidor SSH é inicializado. Portanto, se você receber o aviso de que a chave do host foi alterada, um dos seguintes eventos ocorreu:
- Um novo servidor (ou imagem de máquina, etc.) foi implantado e o endereço IP ou nome de domínio que uma vez apontou para o antigo servidor foi alterado para apontar para o novo servidor (o que é típico, especialmente em ambientes de nuvem ).
- Alguém alterou ou excluiu a chave do host público na máquina. Eu me perguntaria imediatamente por que, como normalmente não há motivo para isso - uma exceção pode ser procedimentos de segurança extremamente rígidos que giram a chave de vez em quando. Mesmo assim, esperaria que a nova impressão da chave pública fosse distribuída para evitar esse erro, nesse caso.
- Alguém conseguiu interceptar o tráfego enviado para esse IP ou nome de domínio e apontou para o próprio servidor em uma tentativa mal-concebida de encenar um ataque SSH do MITM ou, mais provavelmente, tentou inserir para coletar tráfego em uma porta e protocolo separados (como HTTPS).
Se você estiver trabalhando em um ambiente de nuvem, novas imagens e instâncias de máquina serão substituídas o tempo todo para substituir as mais antigas. Portanto, a maneira de remover o aviso e continuar o SSH para o novo host é simplesmente remover a linha ofensiva com a impressão digital antiga do arquivo ~/.ssh/known_hosts . Como boa prática, é melhor remover isso assim que você souber que a substituição aconteceu e, em seguida, faça o login uma vez para confirmar e armazenar a nova chave do host.
Por fim, respeite seus colegas administradores e faça-os saber que isso aconteceu, para que eles não sintam a necessidade de executar o alarme de incêndio por conta própria.
Pós-scriptum (ou checando ssh-keygen -R falhas)
Encontrei uma página semelhante à que você fez , e havia uma nota sobre o novo comportamento que pode alterar a identificação da chave do host público para algum valor com hash, sobre o qual eu não tinha ouvido falar antes - em vez de [vpsXXX.ovh.net] , pode parecer com [BF8JDF9SS@67IX] . Se este for o caso, e você não está editando muito, você pode mover o arquivo known_hosts, conectar via ssh, e isso criará um novo arquivo com uma linha. A linha terá o valor hash correto do domínio ou IP ao qual você se conectou e, assim, você substituirá a chave do host antigo pela nova, do arquivo recém-criado. Mova o arquivo editado de known_hosts de volta ao lugar e voilá— você atualizou sua chave de host pública armazenada para essa conexão.