Imagine a situação: Precisamos validar novo ambiente no Datacenter em Cloud. Estamos de mudança e é plena época de homologação com prazo apertadíssimo! Temos os dois ambientes: um atualmente em uso por anos e o novo para o qual estaremos nos mudando. Os dois ambientes estão conectados via VPN a fim de permitir acessos e cópias de novos dados, etc.
De repente o colega tenta, via scp, copiar uns arquivos novos, então recebe a seguinte mensagem:
# scp /rel_???_2014 abarbosa@192.168.1.22:/tmp/rel_???_2014
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
01:22:46:67:90:ab:cd:ef:01:23:45:67:89:ab:cd:ef.
Please contact your system administrator.
Add correct host key in /home/abarbosa/.ssh/known_hosts to get rid of this message.
Offending key in /home/abarbosa/.ssh/known_hosts:52
RSA host key for 192.168.1.22 has changed and you have requested strict checking.
Host key verification failed.
E agora? Analisando a situação, descobrimos que houve uma mudança, o servidor remoto é virtual e está hospedado em um novo host. Por causa disso, na tentativa de acesso via ssh, o mesmo protocolo usado para o scp, o usuário acabou recebendo este “aviso”.
Este aviso lhe alerta sobre uma diferença entre a identificação digital que está sendo recebida neste acesso e a identificação digital que você aceitou no primeiro acesso ao mesmo servidor. A ideia é lhe prevenir contra “man-in-the-middle-attack”, ou seja, dados serem interceptados por homem ao meio. Como diz a Wikipédia:
Durante o ataque man-in-the-middle, a comunicação é interceptada pelo atacante e retransmitida por este de uma forma discricionária. O atacante pode decidir retransmitir entre os legítimos participantes os dados inalterados, com alterações ou bloquear partes da informação.
Perigoso? Por isso, são geradas chaves RSA. O Blog Lambda3 explica:
Com o RSA eu tenho duas chaves: uma pública e uma privada. A chave pública, como nome diz, eu posso distribuir livremente; qualquer pessoa pode usar a minha chave publica para criptografar uma mensagem para mim. Entretanto, só é possível descriptografar a mensagem usando a minha chave privada, que eu mantenho em segredo.
Assim quando o colega tentou se comunicar com servidor, o terminal percebeu que a chave RSA mudou e isso está afetando o reconhecimento da impressão digital com segurança, já que os dados estão sendo produzidos com base em uma chave diferente.
Se algo assim acontecer, e você não estiver ciente de nenhuma mudança em servidores, não duvide desta mensagem e procure investigar o que está acontecendo. Mas assim como ocorre no meu caso, se você souber que realmente houve uma mudança de host, então poderá adotar procedimentos para se livrar da mensagem e prosseguir com o acesso.
Pode-se resolver isso por apagar a linha informada na mensagem. Você poderá usar o comando de linha de comando “sed” (Stream Editor).
# sed -i '52d' .ssh/known_hosts
O parâmetro -i significa modo de edição (in-place) e d para deletar. Então, entre aspas simples, definimos o número linha que queremos deletar (No meu exemplo é apresentado a linha 52), seguido pelo parâmetro “d”. Por fim, a logo a frente é necessário informar qual o arquivo a ser alterado, e normalmente segue-se como no exemplo .ssh/known_hosts , neste caso para o usuário abarbosa.
Feito isso, quando você tentar um novo acesso via ssh, poderá receber uma mensagem:
# ssh 192.168.1.22
The authenticity of host '192.168.1.22 (192.168.1.22)' can't be established.
RSA key fingerprint is ab:cd:ef:ab:cd:ef:ab:cd:ef:ab:cd:ef:ab:cd:ef:ab.
Are you sure you want to continue connecting (yes/no)?
Esta mensagem solicita uma confirmação de acesso, já que não fora possível encontrar uma chave de impressão digital. Por confirmar o acesso, você será capaz de se conectar normalmente no host remoto.
Mas esse procedimento acima pode ser feito ainda de outra maneira ainda mais fácil. Utilize o comando:
# ssh-keygen -R 192.168.1.22
Este comando irá fazer a edição para você, inclusive criando um backup do arquivo known_hosts como known_hosts.old. Mas obviamente, se você edita-lo novamente usando a mesma ferramenta, o Backup known_hosts.old será substituído por nova cópia.
Agora, quando você tentar novamente o acesso via ssh, poderá receber a mensagem:
# ssh 192.168.1.22
The authenticity of host '192.168.1.22 (192.168.1.22)' can't be established.
RSA key fingerprint is ab:cd:ef:ab:cd:ef:ab:cd:ef:ab:cd:ef:ab:cd:ef:ab.
Are you sure you want to continue connecting (yes/no)?
Novamente, esta mensagem solicita uma confirmação de acesso, já que não fora possível encontrar uma chave de impressão digital. Por confirmar o acesso, você será capaz de se conectar normalmente no host remoto.
Independente a forma que você preferiu realizar o procedimento, se não houver nenhuma outra alteração de servidor ou enquanto não haver nenhum problema de DNS, você não deverá receber mais nenhuma mensagem.
[]’s