ssh: Nie można ustalić autentyczności hosta „nazwa hosta”

Kiedy łączę się z maszyną, czasami pojawia się to ostrzeżenie o błędzie i monituje powiedzieć „tak” lub „nie”. Powoduje to pewne problemy podczas uruchamiania ze skryptów, które automatycznie ssh na inne maszyny.

Wiadomość ostrzegawcza:

The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is    SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.

Czy istnieje sposób, aby automatycznie powiedzieć „tak” lub zignorować to?

W zależności od klienta ssh, możesz ustawić opcję StrictHostKeyChecking na no w wierszu poleceń i / lub wysłać klucz do pustego pliku known_hosts. Możesz także ustawić te opcje w swoim pliku konfiguracyjnym, albo dla wszystkich hostów, albo dla danego zestawu adresów IP lub nazw hostów.

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

EDYTOWAĆ

Jak zauważa @IanDunn, istnieje zagrożenie bezpieczeństwa. Jeśli zasób, z którym się łączysz, został sfałszowany przez atakującego, może on potencjalnie odtworzyć z powrotem wyzwanie serwera docelowego, oszukując Cię do myślenia, że ​​łączysz się ze zdalnym zasobem, podczas gdy w rzeczywistości łączą się z tym zasobem za pomocą Twoje poświadczenia. Powinieneś dokładnie rozważyć, czy jest to odpowiednie ryzyko, zanim zmienisz mechanizm połączenia, aby pominąć HostKeyChecking.

Odniesienie .

Stare pytanie, które zasługuje na lepszą odpowiedź.

Możesz zapobiec interaktywnemu monitowaniu bez wyłączania StrictHostKeyChecking(co jest niebezpieczne).

Uwzględnij w swoim skrypcie następującą logikę:

if [ -z "$(ssh-keygen -F $IP)" ]; then
  ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi

Sprawdza, czy znajduje się klucz publiczny serwera known_hosts. Jeśli nie, żąda klucza publicznego od serwera i dodaje go do known_hosts.

W ten sposób jesteś narażony na atak Man-In-The-Middle tylko raz, który może zostać złagodzony przez:

• upewnienie się, że skrypt po raz pierwszy łączy się przez bezpieczny kanał
• inspekcja logów lub znanych_hostów w celu ręcznego sprawdzenia odcisków palców (do zrobienia tylko raz)

Aby wyłączyć (lub kontrolować wyłączanie), dodaj następujące wiersze na początku /etc/ssh/ssh_config...

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

Opcje:

• Może to być podsieć hosta * zezwalać na nieograniczony dostęp do wszystkich adresów IP.
• Edytuj /etc/ssh/ssh_configkonfigurację globalną lub ~/.ssh/configkonfigurację specyficzną dla użytkownika.

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

Podobne pytanie na superuser.com - patrz https://superuser.com/a/628801/55163

Upewnij się, że ~/.ssh/known_hostsmożna zapisywać. To naprawiło to dla mnie.

Najlepszym sposobem na to jest użycie „BatchMode” oprócz „StrictHostKeyChecking”. W ten sposób twój skrypt zaakceptuje nową nazwę hosta i zapisze ją do pliku znane_hosts, ale nie będzie wymagał interwencji tak / nie.

ssh -o BatchMode=yes -o StrictHostKeyChecking=no [email protected] "uptime"

Edytuj swój plik konfiguracyjny normalnie znajdujący się w '~ / .ssh / config' i na początku pliku dodaj poniższe linie

Host *
    User                   your_login_user
    StrictHostKeyChecking  no
    IdentityFile          ~/my_path/id_rsa.pub

Użytkownik ustawiony na your_login_usermówi, że to ustawienie należy do your_login_user
StrictHostKeyChecking ustawione na no pozwoli uniknąć monitu
IdentityFile to ścieżka do klucza RSA

To działa dla mnie i moich scenariuszy, powodzenia.

To ostrzeżenie jest generowane z powodu funkcji zabezpieczeń, nie wyłączaj tej funkcji.

Jest wyświetlany tylko raz.

Jeśli nadal pojawia się po drugim połączeniu, problem prawdopodobnie dotyczy zapisu do known_hostspliku. W takim przypadku otrzymasz również następujący komunikat:

Failed to add the host to the list of known hosts 

Możesz to naprawić, zmieniając właściciela lub zmieniając uprawnienia do pliku, aby użytkownik mógł go zapisywać.

sudo chown -v $USER ~/.ssh/known_hosts

W nawiązaniu do odpowiedzi Coriego zmodyfikowałem ją i użyłem poniższego polecenia, które działa. Bez tego exitpozostałe polecenie faktycznie logowało się do zdalnego komputera, czego nie chciałem w skrypcie

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"

Zrób to -> chmod +w ~/.ssh/known_hosts. To dodaje uprawnienia do zapisu do pliku pod adresem ~/.ssh/known_hosts. Następnie zdalny host zostanie dodany do known_hostspliku przy następnym połączeniu z nim.

Najlepiej byłoby utworzyć samodzielnie zarządzany urząd certyfikacji. Zacznij od wygenerowania pary kluczy: ssh-keygen -f cert_signer

Następnie podpisz publiczny klucz hosta każdego serwera: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Spowoduje to wygenerowanie podpisanego publicznego klucza hosta: /etc/ssh/ssh_host_rsa_key-cert.pub

W programie /etc/ssh/sshd_configwskaż HostCertificateten plik: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Uruchom ponownie usługę sshd: service sshd restart

Następnie na kliencie SSH dodaj następujące elementy do ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

Powyższe zawiera:

• @cert-authority
• Domena *.example.com
• Pełna zawartość klucza publicznego cert_signer.pub

Plik cert_signerKlucz publiczny zaufa dowolnego serwera, którego gospodarzem publiczny klucz podpisuje cert_signerkluczem prywatnym.

Chociaż wymaga to jednorazowej konfiguracji po stronie klienta, można ufać wielu serwerom, w tym tym, które nie zostały jeszcze zainicjowane (o ile podpisujesz każdy serwer).

Aby uzyskać więcej informacji, zobacz tę stronę wiki .

Zwykle ten problem występuje, gdy bardzo często modyfikujesz klucze. W zależności od serwera aktualizacja nowego klucza, który wygenerowałeś i wkleiłeś na serwerze, może zająć trochę czasu. Więc po wygenerowaniu klucza i wklejeniu na serwerze odczekaj 3 do 4 godzin, a następnie spróbuj. Problem powinien zostać rozwiązany. Zdarzyło się to ze mną.

Dodaj je do swojego / etc / ssh / ssh_config

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Uruchom to na serwerze hosta, to problem z przeczuciem

chmod -R 700 ~/.ssh

Popełniłem ten sam błąd i chciałem zwrócić uwagę na to, że - tak jak mi się to właśnie przydarzyło - możesz mieć po prostu złe uprawnienia.
Skonfigurowałeś .sshkatalog jako zwykły lub jako rootużytkownik, więc musisz być właściwym użytkownikiem. Kiedy pojawił się ten błąd, byłem, rootale skonfigurowałem .sshjako zwykły użytkownik. Wyjście rootnaprawiło to.

Rozwiązuję problem, który powoduje poniżej napisany błąd:
Błąd:
Nie można ustalić autentyczności hosta „XXX.XXX.XXX”.
Odcisk cyfrowy klucza RSA to 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89.

Rozwiązanie:
1. zainstaluj dowolne narzędzie openSSH.
2. uruchom polecenie ssh
3. zapyta o dodanie tego hosta jak. zaakceptuj TAK.
4. Ten host doda do znanej listy hostów.
5. Teraz możesz połączyć się z tym hostem.

To rozwiązanie działa teraz ......