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

Jak mogę uniknąć weryfikacji hosta przez SSH dla znanych hostów?

Otrzymuję następujący monit za każdym razem, gdy próbuję połączyć się z serwerem za pomocą SSH. Wpisuję “tak”, ale czy jest jakiś sposób, aby to ominąć? 

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)?
Źródło

Odpowiedzi (8)

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

Użyj opcji -o, 

ssh -o "StrictHostKeyChecking no" user@host
```.
Źródło
108
108
108
2013-08-06 21:56:17 +0000

Dodaj następujące linie do początku /etc/ssh/ssh_config… 

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

Opcje:

  • Podsieć Host może być *, aby umożliwić nieograniczony dostęp do wszystkich IP.
  • Edytuj /etc/ssh/ssh_config dla konfiguracji globalnej lub ~/.ssh/config dla konfiguracji specyficznej dla użytkownika.

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

Źródło
28
28
28
2010-03-29 09:47:30 +0000

Powinieneś dostać to tylko przy pierwszym połączeniu z nowym hostem. Po tym jak odpowiesz yes, host zostanie zapisany w ~/.ssh/known_hosts i nie otrzymasz monitu przy następnym połączeniu.

Zauważ, że jeśli ~/.ssh/known_hosts nie może być zapisany z jakiegoś powodu (np. problem z uprawnieniami), to będziesz dostawał monit przy każdym połączeniu.
Źródło
11
11
11
2010-06-08 22:29:47 +0000

Najlepszym sposobem (ponieważ nie poświęca bezpieczeństwa) jest połączenie się raz do wszystkich komputerów z jednego klienta (będziesz pytany za każdym razem, zawsze odpowiadaj tak). Jak wskazano w innej odpowiedzi, klucze będą wtedy przechowywane w ~/.ssh/known_hosts. Następnie skopiuj ten plik do każdego komputera klienckiego, z którego możesz później chcieć się połączyć (być może dla każdego konta użytkownika, którego używasz). Wtedy wszystkie te konta będą “znały” te komputery, stąd brak podpowiedzi.

Zaletą wyłączenia monitu jest to, że SSH może faktycznie sprawdzić, czy istnieje atak MITM.
Źródło
1
1
1
2015-07-11 23:20:24 +0000

Jeśli chcesz wyłączyć potwierdzanie, a nie uwierzytelnianie, możesz użyć opcji: “-o CheckHostIP=no” 

ssh -i sergeys_rsa_key.pem -o CheckHostIP=no brin@8.8.8.8
```.
Źródło
0
0
0
2015-12-12 18:09:32 +0000

Jest to prawdopodobnie spowodowane zmianą serwera klucza ssh, ponieważ adres IP serwera lub domena są takie same, ale klucz ssh jest niedopasowany.

Musisz usunąć klucz przechowywany w /home/$user/.ssh/known_hosts aby uniknąć tej wiadomości.

Naprawiłem to usuwając wszystkie klucze w tym pliku, więc nowy token jest tworzony dla tej nazwy domeny.
Źródło
0
0
0
2020-01-27 07:10:41 +0000

Miałem do czynienia z podobnym problemem, gdzie pomimo użycia powyższego sprawdzonego rozwiązania, mój ssh nie działał, a to dlatego, że brakowało pliku known_hosts w katalogu ~/.ssh/, a system plików był tylko do odczytu. SO podczas uruchamiania również nie byłem w stanie utworzyć pliku ~/.ssh/known_hosts.

Jeśli napotkasz podobny problem, sprawdź czy możesz zapisać plik known_hosts w lokalizacji /tmp. Jest to w większości przypadków możliwe nawet w systemie plików tylko do odczytu.

Później w poleceniu ssh możesz określić, aby ssh odczytał plik knownhosts z lokalizacji /tmp. 

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

Sprawdź uprawnienia w swoim pliku ~/.ssh/known_hosts. Moje były nieprawidłowe, gdy miałem ten problem. Naprawiłem to za pomocą: 

chmod 0600 ~/.ssh/known_hosts
Źródło