Jak źle jest mieć wiele urządzeń z tymi samymi kluczami serwera SSH?

Pracuję na wbudowanym urządzeniu z systemem FreeBSD i SSH.

Jak wiesz, sshd lubi losowo generować zestaw kluczy serwera podczas pierwszego uruchamiania. Problem polega na tym, że wyślemy produkt z systemem plików sd-card tylko do odczytu (bez możliwości negocjacji).

Moje dwie opcje, jak je widzę, to:

• Wyślij te same klucze serwera sshd na wszystkie urządzenia
• Zamontuj system plików pamięci i generuj klucze serwera przy każdym rozruchu (powoli ...)

Czy wysyłanie tych samych kluczy serwera na wszystkich urządzeniach jest poważnym problemem w zakresie bezpieczeństwa? Te elementy nie będą bezpośrednio w Internecie. Czasami będzie wiele urządzeń należących do tej samej osoby i w tej samej sieci.

Przez większość czasu urządzenie nie będzie podłączone do Internetu.

Logowanie za pomocą SSH nie jest częścią normalnej pracy. Jest to głównie dla wygody programistów i techników. Klienci nie będą logować się do urządzenia za pomocą SSH.

Jakie są konsekwencje używania tych samych kluczy serwera na wielu urządzeniach?

PS czy ktoś mógłby stworzyć tag internetu rzeczy?

EDYCJA : Mówię o instalacji tego samego klucza prywatnego hosta na wszystkich serwerach (urządzeniach). Jeśli chodzi o klucze publiczne / prywatne użytkownika, obecnie nie ma planów używania logowania na podstawie klucza - byłoby to logowanie za pomocą hasła. Ponownie to samo hasło na wszystkich serwerach (urządzeniach).

Wiem, że to chyba zły pomysł. Chciałbym jednak wiedzieć, dlaczego to zły pomysł, aby zrozumieć kompromisy.

Zamiast przechowywać dane specyficzne dla hosta, takie jak klucze hosta ssh na karcie SD lub innym nośniku tylko do odczytu, można je przechowywać w pamięci NVRAM, czyli do czego służy w systemie wbudowanym. Będziesz musiał wykonać niestandardowe skrypty, aby przechowywać i odzyskiwać klucze w czasie uruchamiania, ale skrypty będą dokładnie takie same dla każdego urządzenia.

Wpływ wysyłki tej samej pary kluczy ze wszystkimi urządzeniami jest bezpośrednio związany z bezpieczeństwem klientów łączących się z nimi, ponieważ oznacza to, że nie ma możliwości (od klienta SSH) jednoznacznej identyfikacji urządzenia, z którym może się łączyć. W razie wycieku pary kluczy można jej użyć do ataków MITM.

Z drugiej strony, ponowne wygenerowanie kluczy przy każdym uruchomieniu spowoduje także wyświetlenie ostrzeżenia dla klientów.

Dla odniesienia man ssh(1):

sshautomatycznie utrzymuje i sprawdza bazę danych zawierającą dane identyfikacyjne dla wszystkich hostów, z którymi kiedykolwiek była używana. Klucze hosta są przechowywane w ~/.ssh/known_hostskatalogu osobistym użytkownika. Ponadto plik /etc/ssh/ssh_known_hostsjest automatycznie sprawdzany pod kątem znanych hostów. Wszelkie nowe hosty są automatycznie dodawane do pliku użytkownika. Jeśli identyfikator hosta kiedykolwiek się zmieni, sshostrzega o tym i wyłącza uwierzytelnianie hasłem, aby zapobiec fałszowaniu serwerów lub atakom typu man-in-the-middle, które w przeciwnym razie mogłyby zostać wykorzystane do obejścia szyfrowania. StrictHostKeyCheckingOpcja może być używany do sterowania maszynami loginów do których klucz hosta nie jest znany lub nie zmieniło.

Wygląda na to, że w pierwszej opcji klucze SSH byłyby dostępne na karcie SD. Aby każdy użytkownik mógł wziąć kartę i odczytać ją. Zasadniczo twoje klucze prywatne stały się (głównie) publiczne.

Umożliwi to ataki typu man-the-the-middle, takie jak:

1. Użytkownik konfiguruje serwer SSH z kluczami prywatnymi uzyskanymi z urządzenia i przekazuje ten adres IP technikowi.
2. Twój technik wprowadza hasło roota przez połączenie SSH.
3. Użytkownik zna teraz hasło roota, które jest ważne dla wszystkich twoich urządzeń.

Jednak nie powinieneś używać haseł roota, zamiast tego użyj kluczy ssh do uwierzytelnienia. Zatem wpływ kluczy serwera współdzielonego jest niewielki, jeśli logujesz się tylko z sieci LAN.

SSH zapewnia również tajemnicę przekazywania, więc osoba atakująca musi mieć możliwość skonfigurowania fałszywego serwera, aby móc korzystać z kluczy; pasywne wąchanie ruchu nie pozwoli na jego odszyfrowanie.

Przeczytałem to z przerażeniem! Ja, który wykonałem wiele komputerów w tym samym klastrze z tym samym kluczem hosta ssh, nigdy nie odważyłbym się tego zrobić. W żadnym wypadku nie zezwalaj komputerom z różnymi zestawami administratorów na współdzielenie kluczy hosta ssh. W ten sposób kryje się szaleństwo i krzyczący horror, gdy dostajesz wiadomość za brak bezpieczeństwa.

Oto mówię prawdę, ten, kto naruszy jedno urządzenie, narazi je wszystkie. Po zdobyciu jednego, spodziewaj się, że źli ludzie będą skakać od jednego do drugiego do woli, a bezpieczeństwo wycofało się, jakby to był cienki papier.

Ponieważ wspominasz, że dostęp SSH nie jest używany przez użytkownika końcowego / klienta, możesz chcieć domyślnie wyłączyć dostęp SSH i włączyć go tylko tymczasowo, gdy urządzenie przejdzie w tryb „debugowania”.

Następnie możesz wysłać wszystkie urządzenia z tym samym kluczem, zakładając, że chroniłeś tryb „debugowania”, aby nie mógł zostać uruchomiony zdalnie przez osobę próbującą włamać się do urządzenia.

Lub masz wygenerowany nowy klucz, gdy urządzenie przechodzi w tryb „debugowania” - więc nie musisz marnować czasu rozruchu na generowanie kluczy przy każdym włączeniu urządzenia.

Oto przykładowy scenariusz ataku oparty na ograniczeniach:

Jeśli masz urządzenia, powiedz na przykład Raspberry Pi. Jeśli podchodzę i wyciągam kartę SD z jednego, mogę wsunąć kartę SD do własnego komputera, znaleźć klucz sshd i skopiować go w dowolne miejsce. Może biorę własną malinową pi i kartę Ethernet USB. Teraz mogę wsadzić to pomiędzy urządzenie docelowe i gdziekolwiek idą i monitorować połączenia ssh. Kiedy widzę, że urządzenie docelowe próbuje nawiązać połączenie ssh, robię to:

(target) <---> (my evil sshd <--> decrypted traffic <--> ssh) <---> (real server)
                                       |
                                       V
                                    log file

Co to jest? Twoje hasło to „Lubię koty”? Chłopcze, to ciekawy e-mail wysłany do żony. Założę się, że byłoby jeszcze bardziej interesujące, gdyby przeczytała ten e-mail wysłany do żony sąsiadów z sąsiedztwa.

Możliwości są nieograniczone . Cel nigdy się nie dowie, ponieważ klucz sshd jest identyczny z kluczem znalezionym na prawdziwym serwerze. W zależności od fizycznego bezpieczeństwa urządzeń odbierających twoje urządzenie może to być niezwykle trywialne. Nie rób tego

Zamiast tego zrób to, co już zaproponowałeś, ale napraw to . Przed napisaniem obrazu uruchom coś takiego:

ssh-keygen -f some-new-server
cp some-new-server /path/to/the/mounted/image/sshd/key
cp some-new-server.pub /path/to/the/mounted/image/sshd/key.pub

A teraz każdy serwer ma nowy klucz. Ponieważ naprawdę, naprawdę nie chcesz rozpowszechniać kopii klucza. Chodzi mi szczerze, że jest to co najmniej tak złe, jak zrobienie zdjęcia kluczy do domu i przesłanie ich do Internetu za pomocą adresu domowego.