Skopiuj klucze ssh z jednego serwera na inny serwer

Mam serwer (załóżmy, że jego adres IP to abcd), który pozwala użytkownikom zalogować się przez ssh. Teraz chcę zmienić fizyczną maszynę, zachowując IP bez zmian. Aby nowy komputer był nadal dostępny dla takiego użytkownika

$ ssh abcd

Problem polega na tym, że za każdym razem, gdy jeden użytkownik próbuje się zalogować, pojawia się następujący błąd niedopasowania klucza ssh.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
@ OSTRZEŻENIE: ZMIENIŁO SIĘ ZDALNA IDENTYFIKACJA HOSTA! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
JEST MOŻLIWE, ŻE KTOŚ KORZYSTA Z NIESAMOWITEJ!
Ktoś może cię teraz podsłuchiwać (atak człowieka w środku)!
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
02: dc: c6: 18: 1b: 34: b7: 1d: fa: 90: ab: e1: 95: 48: 69: 84.
Skontaktuj się z administratorem systemu.
Dodaj poprawny klucz hosta w /home/user/.ssh/known_hosts, aby pozbyć się tej wiadomości.
Obrażanie klucza w /home/user/.ssh/known_hosts:37
Klucz hosta RSA dla absolwentów został zmieniony i zażądano dokładnego sprawdzenia.
Weryfikacja klucza hosta nie powiodła się.

Wiem, że użytkownik może usunąć wiersz # 37 z pliku ~ / .ssh / known_hosts i następnym razem otrzyma monit o tak / nie. Chcę, aby użytkownik był nieświadomy tej wymiany całego urządzenia i otrzymał monit o podanie hasła.

Jak to zrobić?

ssh

— Souvik Pal
źródło

Czy zdajesz sobie sprawę, że pokonałoby sshto jedyną ochronę przed atakami człowieka w środku i może skutkować wysłaniem hasła bezpośrednio do atakującego zamiast do zamierzonej maszyny? Chyba że wiesz, że nie jesteś odporny na aktywne ataki (na przykład jesteś w tej samej bezpiecznej sieci wewnętrznej, co komputer docelowy), to niszczy sshmodel bezpieczeństwa.

— David Schwartz,

Tak. Oba urządzenia znajdują się w tych samych sieciach wewnętrznych. Nawet użytkownicy są w tej samej sieci wewnętrznej. W tej sytuacji, jakie są moje opcje?

— Souvik Pal

To nie wystarczy. Muszą być w tej samej bezpiecznej sieci wewnętrznej. Oznacza to, że muszą absolutnie w 100% ufać, że żadne urządzenie nie jest podłączone do tej wewnętrznej sieci, która nie jest w 100% bezpieczna, i muszą w 100% ufać wszystkim, którzy mają kontrolę nad tymi urządzeniami lub mogą podłączyć urządzenie do tej sieci. Innymi słowy, w prawie każdym realistycznym scenariuszu jest to zły pomysł.

— David Schwartz,

Jest to całkowicie rozsądne. Replikuję klucze serwera ssh na inny serwer dla HA, więc po zalogowaniu otrzymuję te błędy. Poza tym dostaję e-mail po przełączeniu awaryjnym.

— Matt H

Zgadzam się z Mattem. Jeśli kontrolujesz obie maszyny, a zatem jesteś właścicielem kluczy, przenoszenie klucza hosta z jednej maszyny na drugą w twojej kontroli NIE JEST człowiekiem w środku ataku lub ryzyka. Jeśli łączący się użytkownik ufa kluczowi hosta, nie powinno to mieć znaczenia.

— Ross

Odpowiedzi:

Jak wspomniano w Ethabell , możesz skopiować aktualne klucze hosta na nowy serwer.

Możesz znaleźć klucze hosta, otwierając sshd_configplik (w pudełku mojego Ubuntu 12.04 /etc/ssh/sshd_config). W pliku konfiguracyjnym poszukaj HostKeywpisów. Te wpisy powiedzą ci, gdzie znajdują się pliki kluczy hosta. Powinieneś być w stanie skopiować te pliki na nowy serwer i zaktualizować nowy serwer, sshd_configaby wskazywał na skopiowane klucze (lub po prostu nadpisać pliki, które już istnieją na nowym serwerze).

Zwróć też uwagę na tę sekcję ze strony podręcznika sshd_config, w szczególności część dotyczącą uprawnień:

Określa plik zawierający prywatny klucz hosta używany przez SSH. Domyślną wartością jest /etc/ssh/ssh_host_keydla protokołu w wersji 1, a /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_keya /etc/ssh/ssh_host_rsa_keydla wersji protokołu 2. Należy pamiętać, że sshd (8) odmówi użyć pliku, jeśli jest to grupa / świat inwalidzkim. Możliwe jest posiadanie wielu plików kluczy hosta. Klucze „rsa1” są używane w wersji 1, a „dsa”, „ecdsa” lub „rsa” są używane w wersji 2 protokołu SSH.

— ciężki
źródło

Jeśli posiadasz oryginalny klucz hosta, możesz go przywrócić, co zatrzyma błąd.

Lub możesz wyłączyć StrictHostKeyChecking w pliku konfiguracyjnym sshd.

... Robienie tego jest jednak okropnym, okropnym pomysłem. Jeśli istnieje sposób, aby po prostu uruchomić się ssh-keygen -R server.example.comna komputerach klienckich, byłby to najlepszy sposób - ponieważ wyłączenie sprawdzania klucza hosta jest jak powiedzenie: „Hej. Zaatakuj mnie”. Kiedy coś się zmienia, chcę być niejasny, ale bezpieczeństwo powinno być priorytetem nr 1 w stosunku do ukrywania zmian.

— Ethabelle
źródło

Czy możesz opracować sposób przywracania kluczy hosta na nowszym komputerze?

— Souvik Pal

Możesz spróbować w ten sposób

cat ~/.ssh/id_rsa.pub | ssh <user>@<hostname> 'cat >> .ssh/authorized_keys && echo "Key copied"'

Zauważ, że jeśli folder .ssh jeszcze nie istnieje, powyższe polecenie zakończy się niepowodzeniem. Ponadto przy tworzeniu pliku może być lepsze ustawienie minimalnego możliwego uprawnienia (w zasadzie tylko do odczytu i zapisu tylko dla właściciela). Oto bardziej zaawansowane polecenie:

cat ~/.ssh/id_rsa.pub | ssh <user>@<hostname> 'umask 0077; mkdir -p .ssh; cat >> .ssh/authorized_keys && echo "Key copied"'

Aby uzyskać więcej informacji na temat tego problemu, musisz przejść do tej witryny: Błąd zmiany klucza hosta SSH

— Govind Karamta
źródło