Problema de conexão SSH com o erro "Falha na verificação da chave do host ..."


179

Posso conectar-me a outra máquina Ubuntu na minha LAN via SSH. Nos dois PCs, instalei o openssh-server, mas a partir de outro computador Ubuntu, não consigo conectar ao meu PC via SSH e recebi este erro:

Falha na verificação da chave do host ...


11
Você usa nomes de host ou endereços IP?
Thorbjørn Ravn Andersen

Não semelhante, mas eu tenho o mesmo erro, mas devido a um problema diferente: serverfault.com/questions/494916/...
zengr

Este não é um problema específico do Ubuntu. Pode acontecer com qualquer um sshda linha de comando.
31417 MarkHu

Respostas:


216

"Falha na verificação da chave do host" significa que a chave do host do host remoto foi alterada.

O SSH armazena as chaves do host dos hosts remotos em ~/.ssh/known_hosts. Você pode editar esse arquivo de texto manualmente e remover a chave antiga (você pode ver o número da linha na mensagem de erro) ou usar

ssh-keygen -R hostname

Na página do manual :

-R hostname
Remove todas as chaves pertencentes ao hostname de um arquivo known_hosts. Esta opção é útil para excluir hosts com hash.

(que aprendi com a resposta para É possível remover uma chave de host específica do arquivo known_hosts do SSH? ).


4
Também pode significar que você simplesmente não possui a chave do host do host remoto. Por exemplo, se eu rm ~/.ssh/*, então ssh -o BatchMode=yes root@somewhere, se nada mais estiver errado, irei Host key verification failed. Não é importante se você estiver sempre interativo, mas relevante para scripts que encontrarem o mesmo erro.
Ron Burk

Sem surpresa, ssh-keygen -R example.net:7999produz Host example.net:7999 not found in known_hosts.
Alex

Eu removi o known_hostsarquivo e o ssh novamente. Funcionou.
parisan

arquivo ~/.ssh/known_hostsestá ilegível
João Pimentel Ferreira

128

Se você estiver executando em determinadas situações remotas / de script em que não possui acesso interativo à chave de prompt para adicionar host, contorne-a da seguinte maneira:

$ ssh -o StrictHostKeyChecking=no user@something.example.com uptime

Aviso: Adicionado permanentemente 'something.example.com, 10.11.12.13' (RSA) à lista de hosts conhecidos.


6
+1, essa é uma solução feia, mas em alguns casos de processos de monitoramento automatizados que funcionam com dispositivos dymaic conectados por IP, essa é uma solução simples e aceitável.
Ninsuo 11/11

11
+1 Por exemplo, para execuções de Jenkins, esta é uma boa solução. Obrigado
Lobo

5
@Lobo não posso concordar mais, eu estou usando-o para Jenkins, o que é legalsh """ssh -o StrictHostKeyChecking=No ec2-user@someIpAddress-e2e sudo service tomcat restart"""
prayagupd

Salvou a minha vida. Solução de salva-vidas.
user1735921

10

Às vezes, também há situações em que você está trabalhando no console serial, e a verificação do comando acima no modo detalhado -vmostra que você /dev/ttynão existe, enquanto existe.

ssh -v user@hostname

No caso acima, basta remover /dev/ttye criar um link simbólico de /dev/ttyS0para /dev/tty.

rm /dev/tty
ln -s /dev/ttyS0 /dev/tty

Como alternativa, adicione id_rsa.pubao local remoto, para que a senha não seja solicitada e você obtenha acesso ao login.


6
+1 por aconselhar o uso do parâmetro -v; isso pode ajudar muito ao depurar problemas ssh.
Daniel kullmann 24/07/12

8

No meu caso, isso foi causado por um problema do udev - não havia /dev/ttynó do dispositivo. A solução para mim foi apenas:

sudo mknod -m 666 /dev/tty c 5 0

6

No terminal:

ssh -o StrictHostKeyChecking=no -i YourPublicKey.pem user@example.com uptime

A seguinte mensagem, ou similar, aparecerá:

Warning: Permanently added 'example.com, XX.XXX.XXX.XX' (ECDSA) to the list of known hosts.
 00:47:37 up 3 min,  0 users,  load average: 0.00, 0.00, 0.00

Em seguida, conecte-se ao seu EC2 normalmente:

ssh -i YourPublickey.pem user@example.com

Eu tenho command-line line 0: Bad yes/no/ask argument.porque você erroneamente usar 'Não' em vez de 'não' como argumento paraStrictHostKeyChecking
Axel Bregnsbo

3

Bem, é simplesmente porque o segundo ubuntu requer conexão por chave e não por senha.

Eu sugiro que você use sudo dpkg-reconfigure openssh-serverno seu PC, e então ele deve funcionar corretamente. Ele redefinirá a configuração do openssh e deve retornar à autenticação de senha padrão.

A segunda possibilidade é que já existe uma chave para o seu outro ubuntu no seu PC e que ela mudou, não sendo mais reconhecida. Nesse caso, você terá que editar o arquivo .ssh/authorized_keyspara remover a linha problemática que identifica o seu ubuntu.


3

Este é um tópico antigo e acabei de encontrar esta resposta, acrescentarei o que fiz para resolver isso.

ssh-keygen -f "/home/USER/.ssh/known_hosts" -R HOSTNAME

Eu apenas olhei para a mensagem de erro que ele lançou para mim e disse para executar esse comando para removê-lo da lista de hosts. Depois disso, fiz o seguinte:

ssh-copy-id HOSTNAME

Depois, segui as instruções de lá até que eu consegui ssh no servidor.


Como este comando, estou recebendo como sugestão no ubuntu 12.4.
MaNKuR

2

Isso significa que sua chave do host remoto foi alterada (pode ser a alteração da senha do host),

Seu terminal sugeriu executar este comando como usuário root

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]:4231

Você precisa remover esse nome de host da lista de hosts no seu PC / servidor. Copie o comando sugerido e execute como usuário root.

$ sudo su                                                            // Login as a root user

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]:4231   // Terminal suggested command execute here
Host [www.website.net]:4231 found: line 16 type ECDSA
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

$ exit                                                               // Exist from root user

$ sudo ssh root@www.website.net -p 4231                              // Try again

Espero que isso funcione.


1

Você deve alterar sua chave desta maneira: No erro especificado, localize qual chave do host foi alterada, por exemplo: Chave ECDSA ofensiva em /Users/user-name/.ssh/known_hosts:5, a 5ª chave foi alterada, faça o seguinte:

sed -i '5d' ~/.ssh/known_hosts

Nota: você deve ser root ou ter privilégio para o sudo.


Não, a menos que você esteja fazendo isso por outra pessoa, ele não requer raiz nem sudo. Você está editando o arquivo no seu diretório pessoal. Segundo: para que o comando funcione, é necessário GNU sed.
techraf

Talvez você esteja certo, mas tentei ssh do Mac OSX para o ubuntu-server e tenho que fazer isso. a propósito, obrigado pelo seu comentário.
Amir.AG 14/03

1

você deve colocar a chave rsa do host de destino no host de origem /home/user/.ssh/known_hostsexecutando isso no destino

ssh-keyscan -t rsa @targethost

1

Pode ser que você só precise digitar "yes" quando o ssh confirmar que deseja continuar se conectando.

Como abaixo.

The authenticity of host 'xxx' can't be established.
ECDSA key fingerprint is yyy.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'xxx' (ECDSA) to the list of known hosts.
Enter passphrase for key '/Users/ysy/.ssh/id_rsa':

Em seguida, digite sua senha.

Por favor, preste atenção em "Tem certeza de que deseja continuar se conectando (sim / não)? Sim ". Você deve inserir sim, não entrar.


1

Além de desativar estritamente a verificação de chave do host, você também pode conectar-se digitando:

ssh -o LogLevel=quiet -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no <username@target_machine_ip_or_domain_name>

0

pico ~/.ssh/known_hosts e exclua todas as linhas, depois de apenas reconectar e você receberá uma nova chave.


6
Esta é uma solução perigosa, porque você removerá TODAS as chaves do seu host. A solução aceita, ssh-keygen -R hostnameé melhor.
msanford

0

Minha solução vem desta postagem no blog: Falha na negociação do algoritmo para o SSH Secure Shell Client

Você precisa modificar o arquivo da seguinte maneira:

sudo nano /etc/ssh/sshd_config

E adicione o seguinte:

# Ciphers
Ciphers aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour
KexAlgorithms diffie-hellman-group1-sha1

Basicamente, você tentou soluções diferentes até encontrar uma que possa resolver seu problema. Se as soluções acima não funcionarem, tente esta. Se este não funcionar tão bem, tente outros.


0

Basta fazer "sudo vi /var/root/.ssh/known_hosts" e remover a linha, que contém uma chave para um host ao qual você está tentando se conectar e reconectar novamente.

Não conheço sua situação específica, mas provavelmente esse erro veio com uma mensagem como esta:

my_mac:~ oivanche$ sudo ssh pi@192.168.0.45
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:sx1Z4xyGY9venBP6dIHAoBj0VhDOo7TUVCE2xWXpzQk.
Please contact your system administrator.
Add correct host key in /var/root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /var/root/.ssh/known_hosts:74
ECDSA host key for 192.168.0.45 has changed and you have requested strict checking.
Host key verification failed.

Se você ler o registro com mais cuidado, verá que a chave que você obteve de um host está em conflito com a chave que você já possui - nesse caso, está na linha 74 do arquivo known_hosts (Chave ofensiva do ECDSA em / var / root / .ssh / unknown_hosts: 74). Remova a linha dos known_hosts, salve as alterações e reconecte.


-1
chmod 666 /dev/tty 

é outra solução tty - às vezes, esse arquivo de dispositivo tem permissões incorretas.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.