Chave do host SSH alterada - exceto que na verdade não tem

2

Acabei de tentar o SSH em um servidor que estou fazendo sem problemas por um tempo e recebi um aviso de que a chave do host do servidor foi alterada.

Mas isso não aconteceu!

No servidor, verifiquei a chave de hosts que está sendo referenciada em /etc/ssh/sshd_config e não foi alterada.

No cliente, verifiquei o arquivo known_hosts e a entrada existente continha a chave pública correta. Tentei mover temporariamente o arquivo known_hosts e definir StrictHostKeyChecking to no in /etc/ssh/ssh_config para que ele se conecte automaticamente para que eu possa comparar a chave pública. Quando fiz isso e verifiquei a nova entrada em known_hosts , a parte da chave pública é idêntica a antes!

Então, por que não se conectaria? A única coisa diferente em known_hosts é o sal e o hash do nome do host. Mas desde que eu sou, e sempre tenho, conectado via IP e porta, sem usar o hostname, estes devem certamente estar corretos.

Alguma idéia?

Observe que todos os clientes que tentam se conectar que se conectaram anteriormente estão recebendo esta mensagem. Então não é um problema com o cliente.

EDIT: devo acrescentar que quando me conectei com StrictHostKeyChecking definido como no e criei um novo arquivo known_hosts , quando tentei me conectar novamente usando o novo arquivo known_hosts e StrictHostKeyChecking de volta para yes , conectado sem aviso. Em outras palavras, o novo arquivo known_hosts funcionou sem aviso, enquanto o antigo não funcionou, apesar de ter a mesma chave pública dentro.

    
por melkamo 13.04.2012 / 02:12

1 resposta

4

Você não deve desabilitar a verificação da chave do host para este teste. Quando a mensagem de erro aparece sobre um conflito, ela imprime a impressão digital e, como diz David, informa qual entrada é incompatível no arquivo known_hosts. br>
Você pode comparar a impressão digital com a chave do host; Eu não sei de improviso, mas uma pesquisa na internet lhe dirá.

Algo como ssh-keygen -l -f server-public-key.txt [linuxforms] faria isso.

Além disso, usar ssh -vv e verificar /var/log/auth.log (ou equivalente) deve informar mais sobre o problema

    
por 13.04.2012 / 04:10