Jak usunąć ścisłe sprawdzanie klucza RSA w SSH i na czym polega problem?


42

Mam serwer Linux, który po każdym połączeniu pokazuje mi komunikat, który zmienił klucz hosta SSH:

$ ssh root @ host1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@ OSTRZEŻENIE: ZDALNA IDENTYFIKACJA HOSTA ZOSTAŁA ZMIENIONA! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@ JEST MOŻLIWE, ŻE KTOŚ KORZYSTA Z NIESAMOWITEJ! Ktoś może cię teraz podsłuchiwać (atak man-in-the-middle)! Możliwe jest również, że klucz hosta RSA został właśnie zmieniony. Odcisk palca dla klucza RSA wysłanego przez zdalny host to 93: a2: 1b: 1c: 5f: 3e: 68: 47: bf: 79: 56: 52: f0: ec: 03: 6b. Skontaktuj się z administratorem systemu. Dodaj poprawny klucz hosta w /home/emerson/.ssh/known_hosts, aby pozbyć się tej wiadomości. Obrażający klucz w /home/emerson/.ssh/known_hosts:377

Klucz hosta RSA dla hosta 1 został zmieniony i zażądano dokładnego sprawdzenia. Weryfikacja klucza hosta nie powiodła się.

Przez kilka sekund jestem zalogowany, a następnie zamyka połączenie.

host1: ~ / .ssh # Odczyt ze zdalnego hosta host1: Połączenie zresetowane przez użytkownika Połączenie z hostem 1 zamknięte.

Czy ktoś wie, co się dzieje i co mogę zrobić, aby rozwiązać ten problem?


1
To duplikuje wcześniejsze pytanie: serverfault.com/questions/2988/…
Drew Stephens

Odpowiedzi:


68

Nie usuwaj całego pliku znanego_hosta zgodnie z zaleceniami niektórych osób, co całkowicie unieważnia ostrzeżenie. Jest to funkcja bezpieczeństwa, która ostrzega, że ​​mógł się zdarzyć mężczyzna w środku ataku.

Sugeruję, abyś zidentyfikował, dlaczego uważa, że ​​coś się zmieniło, najprawdopodobniej aktualizacja SSH zmieniła klucze szyfrowania z powodu możliwej luki w zabezpieczeniach. Następnie możesz usunąć tę konkretną linię z pliku znanego_hosta:

sed -i 377d ~/.ssh/known_hosts

Ten d eletes linii 377, jak pokazano po okrężnicy w Ostrzeżenie:

/home/emerson/.ssh/known_hosts:377

Alternatywnie możesz usunąć odpowiedni klucz, wykonując następujące czynności

ssh-keygen -R 127.0.0.1 (obviously replace with the server's IP)

NIE usuwaj całego pliku i upewnij się, że jest to maszyna, z którą chcesz się połączyć przed wyczyszczeniem określonego klucza.


Nie zamierza usunąć ponad 350 serwerów z powodu jednego niedopasowania klucza. Wiesz, dlaczego wciąż zamyka połączenie?
setatakahashi

Czy to nie jest rozwiązane po usunięciu odpowiedniego rekordu znanego_hosta? Jeśli nie, czy możesz uruchomić klienta ssh w trybie pełnym i wkleić go gdzieś.
Adam Gibbins

1
Zamyka maszynę, ponieważ klucz hosta jest nieprawidłowy, tak jak mówi. Jeśli poważnie myślisz o bezpieczeństwie, musisz skontaktować się z administratorem serwera, aby upewnić się, że klucz hosta został zmieniony z uzasadnionego powodu. Jeśli tak, możesz go wymienić, jak wyjaśnił Adam.
Matthew Flaschen

Zastosowałem się do Twojej sugestii, ale $ sed -i "46 d" ~ / .ssh / known_hosts sed: 1: "/Users/myusr/.ssh ...": dodatkowe znaki na końcu polecenia l, więc usunąłem go ręcznie za pomocą vim i zadziałało. Dzięki!
Luis Ramirez-Monterosa

3
Składnia Adama jest prawie poprawna, ale potrzebujesz spacji między „377” a „d”. Ponadto w OS X znane hosty znajdują się w ~ / .ssh / known_hosts; zauważ brak „”. w nazwie pliku.
ktappe

27

Myślę, że chociaż niektóre z odpowiedzi tutaj odnoszą się do zalecanego sposobu działania w pytaniu PO, to nie w pełni odpowiada na pytanie.

Pytanie brzmi: „Jak usunąć ścisłe sprawdzanie klucza RSA w SSH i na czym polega problem?”

Problemem jest tutaj, jak sugerują inni, zmiana hosta prawdopodobnie z powodu ponownej instalacji serwera (najczęstszy scenariusz). A zalecanym rozwiązaniem jest rzeczywiście usunięcie naruszającego klucza z pliku .ssh / Author_keys za pomocą wbudowanego sed.

Jednak nie widziałem żadnych odpowiedzi dotyczących konkretnej części pytania „ Jak usunąć ścisłe sprawdzanie klucza RSA w SSH ”.

Możesz usunąć sprawdzanie StrictHostKey w pliku konfiguracyjnym ssh, zwykle przechowywanym w ~/.ssh/config.

Przykładowy blok hosta znajduje się poniżej:

Host 101
  HostName yourip|hostname
  User youruserid
  IdentityFile /path/to/keyfile
  Port 22
  StrictHostKeyChecking no

Specjalnie dodana linia jest ostatnią, StrictHostKeyChecking noktóra robi właśnie to. W zależności od konkretnego scenariusza może to być przydatne, na przykład uruchamianie wielu zwirtualizowanych kontenerów na dedykowanym serwerze, na kilku serwerach ips, zatrzymywanie i uruchamianie innej instancji na tym samym adresie IP.


3
+1 Ponieważ ten post faktycznie dotyczy ściśle sprawdzonej części komunikatu o błędzie.
Shibumi,

1
+1 ode mnie również za zajęcie się treścią pytania. W zależności od czynników może być więcej do zrobienia. Takie podejście obniża sprawdzanie hosta z „ścisłego” do „niektórych” (moja terminologia). W mojej sytuacji pozostawiłem ssh pozwolenie, aby mnie nie logować, ponieważ sposobem, w jaki chciałem się zalogować, było wprowadzenie hasła, a to zostało wyłączone przez „niektóre” sprawdzanie hosta. Musisz więc iść dalej i polecić ssh, aby używał / dev / null jako „UserKnownHostsFile”. Ustawia to sprawdzanie hosta na „brak” i obowiązują powyższe ostrzeżenia DIRE, więc nie rób tego globalnie lub na stałe.
mężczyzna z Cardiff,

To naprawdę eleganckie rozwiązanie. Dzięki za udostępnienie!
LeOn - Han Li

10

Kolejny sposób na usunięcie StrictHostKeyChecking, gdy musisz to zrobić tylko dla jednego serwera:

ssh <server> -o StrictHostKeyChecking=no

Pozwoli ci się zalogować, ale nie naprawi problemu na stałe.
Andres Canella,

Kiedy to robię, daje mi szansę na dodanie klucza, który następnie rozwiązuje problem na stałe
Greg Dougherty

Być może mamy inny problem? Łączę się z serwerem, który wcześniej miał inny adres IP.
Andres Canella,

Jeśli masz serwer, którego dane uległy zmianie, musisz go usunąć ze znanego pliku hosts (po pierwszym ustaleniu, że zmiana jest poprawna) i dodać nowe informacje. Jeśli masz nowy serwer, -o pozwoli ci połączyć się z serwerem i dodać jego informacje.
Greg Dougherty

Myślę, że właściwie dobrą praktyką jest ustawienie StrictHostKeyChecking na YES w konfiguracji i używanie tego przełącznika tylko wtedy, gdy wiesz, że łączysz się z nowym serwerem lub sam zmieniłeś klucze na starym serwerze.
mohak

5

Przede wszystkim, czy to twoja maszyna? Czy świadomie zmieniłeś klucze hosta? Jeśli nie, byłbym bardzo zaniepokojony, że coś zmieniło te dane.

Po drugie, podkręć debugowanie ssh,

ssh -vvv user@host

i zobacz, co ci to mówi, spróbuj także zajrzeć, / var / log / secure i / var / log / messages na serwerze, z którym próbujesz się połączyć w celu uzyskania wskazówek, sshd daje dobre komunikaty o błędach.

Po trzecie, czy to urządzenie jest podłączone do Internetu? Czy naprawdę powinieneś zezwalać na logowanie do roota?


1
+1 za komentarz do logowania do roota
Fahad Sadah,

Wystąpienie tego błędu wystarczy, aby komputer docelowy był ponownie tworzony. Jeśli łączysz się z celem znajdującym się po Twojej stronie DMZ, atak MitM jest bardzo mało prawdopodobny.
ktappe

3

Otrzymujesz to, ponieważ coś się zmieniło (np. Nowa karta sieciowa, nowy adres IP, zmiana oprogramowania serwera itp.). Bezpieczeństwo koncentruje się na ciekawym artykule na temat ochrony klucza hosta SSH .

Po prostu usuń klucz (używając SFTP lub podobnego) z serwera, edytując $HOME/.ssh/known_hostsplik i zaakceptuj nowy przy następnym połączeniu.

Twoje połączenie może zostać zerwane z powodu ustawienia StrictHostKeyChecking. Zobacz ten wątek dotyczący podobnego problemu.


2
Nieeee, proszę nie rób tego. To całkowicie unieważnia wszelkie zabezpieczenia, jakie zapewnia ta funkcja. Usuń tylko określony klucz, który się zmienił, nie wszystkie znane hosty.
Adam Gibbins

5
Nie zalecałem usuwania pliku znanego_hosta, zaleciłem jego edycję i usunięcie z niego klucza.

Ooop, przepraszam, źle odczytany.
Adam Gibbins

2
Tego komunikatu z pewnością nie może wyzwolić nowy adres IP, a tym bardziej nowa karta sieciowa. Zobacz poprawną odpowiedź Adama Gibbinsa.
bortzmeyer

1
Zanim zagłosujesz (uważam, że ludzie są z tego bardzo zadowoleni), przeprowadź swoje badania. Przeczytaj artykuł Security Focus, securityfocus.com/infocus/1806 . Cytuję go trochę: „Dlaczego klucz hosta może się zmienić? Jeśli odpowiedź jest strasznie niepoprawna, daj szansę na korektę. W końcu jest to wiki.

3

Jako „host” [ogólnie zdefiniowany, może to być wszystko, od ponownej instalacji / uruchamiania wielu urządzeń do zupełnie innego komputera z adresem IP, z którym się wcześniej łączyłeś, na przykład] wydaje się, że klient ssh się zmienił, daje ci błąd.

Nie jest konieczne wyłączanie ścisłego sprawdzania, nie jest też sensowne całkowite usuwanie zapisanych kluczy.

Jest całkiem możliwe, aby mieć dwa różne klucze wymienione w znanych_hostach dla określonej nazwy hosta lub adresu IP; dając dwie możliwości w zależności od tego, czy uważasz, że możesz potrzebować „starego” klucza, który jest obecnie przechowywany w znanych hostach

Usuń konkretny klucz, którego dotyczy, na 377 znanych hostów dla OP, lub zachowaj oba

Najprostszym sposobem na zachowanie obu, unikając usuwania kluczy w znanych_hostach, jest

  1. Edytuj znane_hosty, aby tymczasowo dodać # na początku „starego” wpisu, o którym mowa w znanych_hostach [@ l377]
  2. Połącz [ssh z hostem], zgódź się na monit o dodanie nowego klucza „automatycznie”
  3. Następnie ponownie edytuj znane hosty, aby usunąć #

więcej odpowiedzi na „Dodaj poprawny klucz hosta w znane_hosty” / wiele kluczy hosta ssh na nazwę hosta?


Nie wiedziałem o sztuczce z dwoma kluczami. To nie jest udokumentowane zachowanie, prawda?
hackerb9
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.