2010-03-29 09:43:00 +0000 2010-03-29 09:43:00 +0000
181
181
Advertisement

Como posso evitar a verificação do hospedeiro do SSH para hospedeiros conhecidos?

Advertisement

Recebo a seguinte mensagem sempre que tento ligar um servidor usando SSH. Escrevo “sim”, mas há alguma forma de oovidar isto?

The authenticity of host '111.222.333.444 (111.222.333.444)' can't be established.
RSA key fingerprint is f3:cf:58:ae:71:0b:c8:04:6f:34:a3:b2:e4:1e:0c:8b.
Are you sure you want to continue connecting (yes/no)?
Advertisement
Advertisement

Respostas (8)

254
254
254
2010-03-29 10:53:30 +0000

Use a opção -o,

ssh -o "StrictHostKeyChecking no" user@host
108
108
108
2013-08-06 21:56:17 +0000

Adicione as seguintes linhas ao início de /etc/ssh/ssh_config

Host 192.168.0.*
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

Opções:

  • A sub-rede anfitriã pode ser * para permitir o acesso irrestrito a todos os IPs. & - Editar /etc/ssh/ssh_config para configuração global ou ~/.ssh/config para configuração específica do utilizador.

Ver http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

28
Advertisement
28
28
2010-03-29 09:47:30 +0000
Advertisement

Só deverá obter isto na primeira vez que se ligar a um novo anfitrião. Depois de responder yes o anfitrião é armazenado em ~/.ssh/known_hosts e não será avisado da próxima vez que se ligar.

Note que se ~/.ssh/known_hosts não puder ser escrito por qualquer razão (por exemplo, problema de permissões), então será avisado cada vez que se ligar.

11
11
11
2010-06-08 22:29:47 +0000

A melhor maneira (porque não sacrifica a segurança) é ligar-se uma vez a todos os computadores de um cliente (será sempre solicitado, responderá sempre que sim). Como assinalado na outra resposta, as chaves serão então armazenadas em ~/.ssh/known_hosts. Depois copie este ficheiro para cada computador cliente a partir do qual possa querer ligar-se mais tarde (possivelmente para cada conta de utilizador que utilizar). Então, todas estas contas “conhecerão” os computadores, não havendo, portanto, qualquer solicitação.

A vantagem sobre a simples desactivação do prompt é que o SSH pode realmente verificar se existe um ataque MITM.

1
Advertisement
1
1
2015-07-11 23:20:24 +0000
Advertisement

Se quiser desactivar a confirmação, em vez da autenticação, pode usar a opção: “-o CheckHostIP=no”

ssh -i sergeys_rsa_key.pem -o CheckHostIP=no brin@8.8.8.8
0
0
0
2015-12-12 18:09:32 +0000

Isto é provavelmente porque o seu servidor de chaves ssh mudou, uma vez que o ip ou domínio do servidor é o mesmo, mas o ssh não é compatível com as chaves.

Deve remover a chave armazenada em /home/$user/.ssh/known_hosts para evitar esta mensagem.

Eu corrigi-a removendo todas as chaves nesse ficheiro, pelo que é criado um novo token para este nome de domínio.

0
Advertisement
0
0
2020-01-27 07:10:41 +0000
Advertisement

Tinha enfrentado um problema semelhante em que, apesar de utilizar a solução verificada acima mencionada, o meu ssh não estava a funcionar e era porque o ficheiro de anfitriões conhecidos estava em falta no directório ~/.ssh/ e o Sistema de Ficheiros só era lido. SO durante o tempo de execução também não fui capaz de criar o ficheiro ~/.ssh/known_hosts.

Se se deparar com um problema semelhante, então veja se consegue escrever o ficheiro de ~/.ssh/known_hosts no local /tmp. Isto é na maior parte das vezes possível escrever, mesmo num sistema de ficheiro só de leitura.

Mais tarde no comando ssh pode especificar o ficheiro ssh para ler o ficheiro conhecido_hosts a partir do local /tmp.

ssh -o UserKnownHostsFile=/tmp/known_hosts -o StrictHostKeyChecking=no user_name@destination_server_ip
-2
-2
-2
2018-11-09 12:14:07 +0000

Verifique as permissões no seu ficheiro ~/.ssh/known_hosts. As minhas estavam incorrectas quando recebi este problema. Resolvi-o com:

chmod 0600 ~/.ssh/known_hosts
Advertisement

Questões relacionadas

6
10
19
12
2
Advertisement
Advertisement