Skip to content

Poznaj tajniki OpenSSH na komputerze z systemem Linux

27 de lipiec de 2021
banner bad warning

Wielokrotnie wychwalaliśmy zalety SSH, zarówno pod względem bezpieczeństwa, jak i zdalnego dostępu. Rzućmy okiem na sam serwer, kilka ważnych aspektów „utrzymania” i kilka dziwactw, które mogą dodać turbulencji do płynnej jazdy.

Chociaż napisaliśmy ten przewodnik z myślą o Linuksie, może to również dotyczyć OpenSSH w Mac OS X i Windows 7 za pośrednictwem Cygwin.

Dlaczego jest bezpieczny

Wielokrotnie wspominaliśmy, że SSH to świetny sposób na bezpieczne łączenie i tunelowanie danych z jednego punktu do drugiego. Przyjrzyjmy się pokrótce, jak to wszystko działa, aby lepiej zrozumieć, dlaczego czasami rzeczy mogą wyglądać dziwnie.

1627363475 410 Poznaj tajniki OpenSSH na komputerze z systemem

Decydując się na zainicjowanie połączenia z innym komputerem, często korzystamy z łatwych w obsłudze protokołów. Przychodzą mi na myśl zarówno Telnet, jak i FTP. Wysyłamy informacje na zdalny serwer, a następnie otrzymujemy potwierdzenie naszego połączenia. W celu ustanowienia pewnego rodzaju bezpieczeństwa protokoły te często używają kombinacji nazwy użytkownika i hasła. To znaczy, że są całkowicie bezpieczne, prawda? Zło!

Jeśli myślimy o naszym procesie łączenia się jako o poczcie, to używanie FTP i Telnet i tym podobne nie jest jak używanie standardowych kopert pocztowych. To bardziej jak korzystanie z pocztówek. Jeśli ktoś wejdzie pośrodku, może zobaczyć wszystkie informacje, w tym adresy obu korespondentów oraz wysłaną nazwę użytkownika i hasło. Następnie mogą zmienić wiadomość, zachowując te same informacje, i podszywać się pod jednego lub drugiego korespondenta. Jest to znane jako atak typu „man-in-the-middle” i nie tylko narusza Twoje konto, ale także kwestionuje każdą wysłaną wiadomość i otrzymany plik. Nie możesz być pewien, czy rozmawiasz z nadawcą, czy nie, a nawet jeśli tak, nie możesz być pewien, że nikt nie patrzy na wszystko pomiędzy.


Przyjrzyjmy się teraz szyfrowaniu SSL, takiemu, które sprawia, że ​​HTTP jest bezpieczniejszy. Tutaj mamy pocztę, która zajmuje się korespondencją, która sprawdza, czy Twój odbiorca jest tym, za kogo się podaje, i ma przepisy chroniące Twoją pocztę przed oglądaniem. Ogólnie rzecz biorąc, jest bezpieczniejszy, a organ centralny — Verisign jest jednym z nich, dla naszego przykładu HTTPS — upewnia się, że osoba, do której wysyłasz pocztę, dokonała transakcji. Robią to, nie zezwalając na pocztówki (niezaszyfrowane dane uwierzytelniające); zamiast tego nakazują prawdziwe koperty.

1627363475 349 Poznaj tajniki OpenSSH na komputerze z systemem

Na koniec spójrzmy na SSH. Tutaj konfiguracja jest nieco inna. Nie mamy tutaj centralnego wystawcy uwierzytelnienia, ale wszystko jest nadal bezpieczne. To dlatego, że wysyłasz listy do kogoś, kogo adres już znasz – powiedzmy, rozmawiając z nim przez telefon – i używasz naprawdę wymyślnej matematyki do podpisania koperty. Przekazujesz go swojemu bratu, dziewczynie, tacie lub córce, aby zaniósł go pod wskazany adres, i tylko wtedy, gdy fantazyjne dopasowanie matematyczne odbiorcy zakłada, że ​​adres jest taki, jaki powinien być. Następnie otrzymasz list z powrotem, również chroniony przed wzrokiem ciekawskich przez tę niesamowitą matematykę. Na koniec wysyłasz swoje dane uwierzytelniające w kolejnej sekretnej, zaklętej algorytmicznie kopercie do miejsca docelowego. Jeśli matematyka się nie zgadza, możemy założyć, że pierwotny odbiorca się przeprowadził i musimy ponownie potwierdzić jego adres.

Z wyjaśnieniem tak długo, jak jest, myślimy, że je tam skrócimy. Jeśli masz więcej wglądu, oczywiście możesz porozmawiać w komentarzach. Na razie jednak spójrzmy na najważniejszą funkcję SSH, uwierzytelnianie hosta.

Klucze hosta

Uwierzytelnianie hosta to zasadniczo ta część, w której zaufana osoba bierze kopertę (zapieczętowaną za pomocą magicznej matematyki) i potwierdza adres odbiorcy. Jest to dość szczegółowy opis adresu oparty na skomplikowanej matematyce, którą po prostu pominiemy. Jest jednak kilka ważnych rzeczy, które należy od tego zabrać:

  1. Ponieważ nie ma centralnego organu, prawdziwe bezpieczeństwo leży w kluczu hosta, kluczach publicznych i kluczach prywatnych. (Te dwa ostatnie klucze są konfigurowane, gdy masz dostęp do systemu).
  2. Zwykle, gdy łączysz się z innym komputerem przez SSH, klucz hosta jest przechowywany. Dzięki temu przyszłe działania będą szybsze (lub mniej gadatliwe).
  3. Jeśli klucz hosta ulegnie zmianie, najprawdopodobniej zostaniesz ostrzeżony i powinieneś być ostrożny!

Ponieważ klucz hosta jest używany przed uwierzytelnieniem w celu ustalenia tożsamości serwera SSH, należy sprawdzić klucz przed połączeniem. Zobaczysz okno dialogowe potwierdzenia, jak poniżej.

ostrzeżenie na banerze

Nie powinieneś się jednak martwić! Często, gdy chodzi o bezpieczeństwo, istnieje specjalne miejsce, w którym można potwierdzić klucz hosta (odcisk palca ECDSA powyżej). W przedsięwzięciach całkowicie online, często będzie to miejsce na bezpiecznej stronie tylko do logowania. Być może będziesz musiał (lub zdecydować się!) zadzwonić do działu IT, aby potwierdzić ten klucz przez telefon. Słyszałem nawet o miejscach, w których klucz znajduje się na Twojej plakietce służbowej lub na specjalnej liście „Numery alarmowe”. A jeśli masz fizyczny dostęp do maszyny docelowej, możesz również sam to sprawdzić!

Sprawdzanie klucza hosta systemu

Istnieją 4 rodzaje algorytmów szyfrowania używanych do tworzenia kluczy, ale domyślnym dla OpenSSH na początku tego roku jest ECDSA (z dobrych powodów). Skupimy się na tym dzisiaj. Oto polecenie, które możesz uruchomić na serwerze SSH, do którego masz dostęp:

ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l

Twoje wyjście powinno zwrócić coś takiego:

256 ca:62:ea:7c:e4:9e:2e:a6:94:20:11:db:9c:78:c3:4c /etc/ssh/ssh_host_ecdsa_key.pub


Pierwsza liczba to długość klucza w bitach, następnie sam klucz, a na końcu masz plik, w którym jest przechowywany. Porównaj tę środkową część z tym, co widzisz, gdy zostaniesz poproszony o zdalne zalogowanie. Powinno pasować i gotowe. Jeśli tak się nie stanie, może dziać się coś innego.

Możesz wyświetlić wszystkie hosty, z którymi połączyłeś się przez SSH, przeglądając plik znany_hosts. Zwykle znajduje się pod adresem:

~/.ssh/znane_hosty

Możesz to otworzyć w dowolnym edytorze tekstu. Jeśli spojrzysz, spróbuj zwrócić uwagę na sposób przechowywania kluczy. Są one przechowywane z nazwą komputera hosta (lub adresem internetowym) oraz jego adresem IP.

Zmiana kluczy hosta i problemy

Istnieje kilka powodów, dla których klucze hostów zmieniają się lub nie pasują do tego, co jest zapisane w pliku znane_hosty.

  • System został ponownie zainstalowany/przekonfigurowany.
  • Klucze hosta zostały ręcznie zmienione ze względu na protokoły bezpieczeństwa.
  • Serwer OpenSSH został zaktualizowany i używa innych standardów ze względu na problemy z bezpieczeństwem.
  • Zmieniono dzierżawę adresu IP lub DNS. Często oznacza to, że próbujesz uzyskać dostęp do innego komputera.
  • System został skompromitowany w taki sposób, że zmienił się klucz hosta.

Najprawdopodobniej problem jest jednym z pierwszych trzech i możesz zignorować zmianę. Jeśli dzierżawa IP/DNS uległa zmianie, może to oznaczać problem z serwerem i możesz zostać przekierowany do innego komputera. Jeśli nie masz pewności, jaki jest powód zmiany, prawdopodobnie powinieneś założyć, że jest to ostatnia zmiana na liście.

Jak OpenSSH obsługuje nieznane hosty?

1627363475 610 Poznaj tajniki OpenSSH na komputerze z systemem

OpenSSH ma ustawienie dotyczące obsługi nieznanych hostów, odzwierciedlone w zmiennej „StrictHostKeyChecking” (bez cudzysłowów).


W zależności od konfiguracji połączenia SSH z nieznanymi hostami (którego klucze nie znajdują się jeszcze w pliku znane_hosts) mogą przebiegać na trzy sposoby.

  • StrictHostKeyChecking jest ustawiony na no ; OpenSSH automatycznie połączy się z dowolnym serwerem SSH, niezależnie od statusu klucza hosta. Jest to niebezpieczne i niezalecane, z wyjątkiem sytuacji, gdy dodajesz kilka hostów po ponownej instalacji systemu operacyjnego, po czym zmieniasz je z powrotem.
  • StrictHostKeyChecking jest ustawiony na ask ; OpenSSH pokaże nowe klucze hosta i poprosi o potwierdzenie przed ich dodaniem. Uniemożliwi to połączeniom przejście do zmienionych kluczy hosta. To jest ustawienie domyślne.
  • StrictHostKeyChecking jest ustawiony na yes ; Przeciwieństwo „nie”, uniemożliwi to łączenie się z dowolnym hostem, który nie jest jeszcze obecny w twoim plikuknown_hosts.

Możesz łatwo zmienić tę zmienną w wierszu poleceń, korzystając z następującego paradygmatu:

ssh -o 'StrictHostKeyChecking [option]' user@host

Zastępować [option] z „nie”, „zapytaj” lub „tak”. Należy pamiętać, że wokół tej zmiennej i jej ustawienia znajdują się pojedyncze cudzysłowy. Zastąp także user@host nazwą użytkownika i nazwą hosta serwera, z którym się łączysz. Na przykład:

ssh -o 'StrictHostKeyChecking ask' [email protected]

Zablokowane hosty z powodu zmienionych kluczy

Jeśli masz serwer, do którego próbujesz uzyskać dostęp, a którego klucz został już zmieniony, domyślna konfiguracja OpenSSH uniemożliwi dostęp do niego. Mógłbyś zmienić wartość StrictHostKeyChecking dla tego hosta, ale nie byłoby to całkowicie, całkowicie, paranoicznie bezpieczne, prawda? Zamiast tego możemy po prostu usunąć naruszającą wartość z naszego pliku znane_hosts.

złe ostrzeżenie

To zdecydowanie brzydka rzecz na ekranie. Na szczęście naszym powodem była reinstalacja systemu operacyjnego. Powiększmy więc linię, której potrzebujemy.

1627363476 214 Poznaj tajniki OpenSSH na komputerze z systemem


No to jedziemy. Widzisz, jak cytuje plik, który musimy edytować? Daje nam nawet numer linii! Otwórzmy więc ten plik w Nano:

1627363476 566 Poznaj tajniki OpenSSH na komputerze z systemem

1. linia

Oto nasz obraźliwy klawisz, w wierszu 1. Wszystko, co musimy zrobić, to nacisnąć Ctrl + K, aby wyciąć całą linię.

po pierwszej linii

To jest o wiele lepsze! Więc teraz naciskamy Ctrl + O, aby zapisać (zapisać) plik, a następnie Ctrl + X, aby wyjść.

Teraz zamiast tego otrzymujemy miły monit, na który możemy po prostu odpowiedzieć „tak”.

wszystko zrobione

Tworzenie nowych kluczy hosta

Dla przypomnienia, naprawdę nie ma zbyt dużego powodu, aby w ogóle zmieniać klucz hosta, ale jeśli kiedykolwiek znajdziesz taką potrzebę, możesz to zrobić łatwo.

Najpierw przejdź do odpowiedniego katalogu systemowego:

cd /etc/ssh/

Zwykle jest to miejsce, w którym znajdują się globalne klucze hosta, chociaż niektóre dystrybucje umieszczają je gdzie indziej. W razie wątpliwości sprawdź swoją dokumentację!

Następnie usuniemy wszystkie stare klucze.

sudo rm /etc/ssh/ssh_host_*


Alternatywnie możesz przenieść je do bezpiecznego katalogu kopii zapasowych. Tylko myśl!

Następnie możemy nakazać serwerowi OpenSSH rekonfigurację:

sudo dpkg-reconfigure openssh-server

Zobaczysz monit, gdy komputer utworzy nowe klucze. Ta-da!

tworzenie kluczy

Teraz, gdy wiesz, jak SSH działa trochę lepiej, powinieneś być w stanie wydostać się z trudnych sytuacji. Ostrzeżenie / błąd „Zdalna identyfikacja hosta uległa zmianie” to coś, co zniechęca wielu użytkowników, nawet tych, którzy znają wiersz poleceń.

Aby uzyskać dodatkowe punkty, możesz sprawdzić Jak zdalnie kopiować pliki przez SSH bez podawania hasła. Tam dowiesz się trochę więcej o innych rodzajach algorytmów szyfrowania oraz o tym, jak używać plików kluczy w celu zwiększenia bezpieczeństwa.

Czy ten post był pomocny?