Poznaj Ins i Out of OpenSSH na swoim komputerze z systemem Linux

Wielokrotnie wychwalaliśmy zalety SSH, zarówno dla bezpieczeństwa, jak i zdalnego dostępu. Przyjrzyjmy się samemu serwerowi, kilku ważnym aspektom "konserwacyjnym" i niektórym dziwactwom, które mogą dodać turbulencje 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 przez Cygwin.

Dlaczego jest bezpieczny

Wielokrotnie wspominaliśmy, jak SSH to świetny sposób na bezpieczne połączenie i tunelowanie danych z jednego punktu do drugiego. Przyjrzyjmy się bardzo krótko, jak działają rzeczy, aby uzyskać lepsze wyobrażenie o tym, dlaczego czasami może być dziwnie.

Kiedy decydujemy się zainicjować połączenie z innym komputerem, często używamy protokołów, z którymi łatwo się pracuje. Telnet i FTP zarówno przychodzą na myśl. Wysyłamy informacje do zdalnego serwera, a następnie otrzymujemy potwierdzenie z powrotem o naszym połączeniu. Aby ustanowić pewien rodzaj bezpieczeństwa, protokoły te często używają kombinacji nazwy użytkownika i hasła. Oznacza to, że są całkowicie bezpieczne, prawda? Źle!

Jeśli myślimy o naszym procesie łączenia jako e-mail, to używanie FTP i Telnetu itp. Nie jest jak używanie standardowych kopert mailingowych. To bardziej przypomina korzystanie z pocztówek. Jeśli zdarzy się, że ktoś stanie na środku, zobaczy wszystkie informacje, w tym adresy obu korespondentów oraz nazwę użytkownika i hasło wysłane. Mogą następnie zmienić wiadomość, zachowując informacje takie same i podszywać się pod jednego lub drugiego korespondenta. Jest to znany 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 jesteś, nie możesz być pewien, że nikt nie patrzy na wszystko z.

Teraz spójrzmy na szyfrowanie SSL, które sprawia, że HTTP jest bezpieczniejszy. Tutaj mamy urząd pocztowy, który zajmuje się korespondencją, która sprawdza, czy odbiorca jest tym, za kogo się podaje i czy nie ma przepisów chroniących twoją pocztę przed obejrzeniem. Jest ogólnie bezpieczniejszy, a centralny autorytet - Verisign jest jednym z naszych przykładów HTTPS - zapewnia, że osoba, z którą wysyłasz pocztę, wykaże się. Robią to, nie zezwalając na pocztówki (niezaszyfrowane dane uwierzytelniające); zamiast tego zlecają prawdziwe koperty.

Na koniec spójrzmy na SSH. Tutaj konfiguracja jest trochę inna. Nie mamy tu centralnego uwierzytelniającego, ale wszystko jest nadal bezpieczne. Dzieje się tak dlatego, że wysyłasz listy do kogoś, kogo już znasz - powiedzmy, rozmawiając z nimi przez telefon - i używasz naprawdę wymyślnej matematyki do podpisania swojej koperty. Przekazujesz ją swojemu bratu, dziewczynie, tacie lub córce, by zabrać ją pod adres, i tylko wtedy, gdy pasujące mecze matematyczne odbiorcy przyjmujesz, że adres jest tym, czym powinien być. Następnie otrzymasz list z powrotem, również chroniony przed wścibskimi oczami przez tę niesamowitą matematykę. Na koniec wysyłasz swoje poświadczenia w innej zakodowanej algorytmicznie kopercie do miejsca przeznaczenia. Jeśli matematyka się nie zgadza, możemy założyć, że pierwotny adresat się przeniósł i musimy ponownie potwierdzić jego adres.

Z wyjaśnieniem tak długo, jak to jest, uważamy, że go tam wytniemy. Jeśli masz więcej wglądu, oczywiście możesz czatować w komentarzach. Na razie jednak spójrzmy na najbardziej istotną cechę SSH, uwierzytelnianie hosta.

Klucze główne

Uwierzytelnianie hosta to w zasadzie część, w której zaufana osoba przyjmuje kopertę (zapieczętowana za pomocą magicznej matematyki) i potwierdza adres odbiorcy. Jest to dość szczegółowy opis adresu, i jest oparty na skomplikowanej matematyce, którą po prostu pomijamy. Jest jednak kilka ważnych rzeczy do usunięcia:

Ponieważ nie ma centralnego organu, rzeczywiste bezpieczeństwo leży w kluczu głównym, kluczach publicznych i kluczach prywatnych. (Te ostatnie dwa klawisze są skonfigurowane, gdy masz dostęp do systemu.)
Zwykle po połączeniu się z innym komputerem przez SSH klucz hosta jest przechowywany. To sprawia, że przyszłe działania są szybsze (lub mniej szczegółowe).
Jeśli klucz hosta ulegnie zmianie, najprawdopodobniej zostaniesz ostrzeżony i powinieneś zachować ostrożność!

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

Nie powinieneś się jednak martwić! Często, gdy bezpieczeństwo jest problemem, będzie specjalne miejsce, w którym klucz hosta (odcisk palca ECDSA powyżej) może zostać potwierdzony. W przedsięwzięciach całkowicie online, często będzie na bezpiecznej stronie logowania tylko. Być może trzeba (lub wybrać!) Zadzwonić do działu IT, aby potwierdzić ten klucz przez telefon. Słyszałem nawet o niektórych miejscach, w których klucz znajduje się na plakietce pracy lub na specjalnej liście "Numery alarmowe". A jeśli masz fizyczny dostęp do maszyny docelowej, możesz sam sprawdzić!

Sprawdzanie klucza hosta systemu

Istnieją 4 rodzaje algorytmów szyfrowania używanych do tworzenia kluczy, ale domyślną wartością dla OpenSSH na początku tego roku jest algorytm ECDSA (z pewnych 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 wyniki powinny zwracać 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, następnie klucz, a na końcu masz plik, w którym jest on przechowywany. Porównaj średnią część z tym, co zobaczysz, gdy pojawi się monit o zdalne zalogowanie. Powinien pasować, a ty wszystko gotowe. Jeśli nie, to może się zdarzyć coś innego.

Możesz przeglądać wszystkie hosty połączone z SSH, przeglądając plik known_hosts. Zwykle znajduje się w:

~ / .ssh / known_hosts

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

Zmiana kluczy hosta i problemów

Istnieje kilka powodów, dla których klucze hosta ulegają zmianie lub nie pasują do tego, co jest zapisane w pliku known_hosts.

System został ponownie zainstalowany / ponownie skonfigurowany.
Klucze hosta zostały ręcznie zmienione ze względu na protokoły bezpieczeństwa.
Serwer OpenSSH został zaktualizowany i używa różnych standardów ze względu na problemy z bezpieczeństwem.
Zmiana dzierżawy adresu IP lub DNS. To często oznacza, że próbujesz uzyskać dostęp do innego komputera.
System został w jakiś sposób upośledzony, tak że zmieniono klucz hosta.

Najprawdopodobniej problem jest jednym z pierwszych trzech i możesz zignorować tę zmianę. Jeśli dzierżawa IP / DNS uległa zmianie, może to oznaczać problem z serwerem i może zostać przekierowany na inny komputer. Jeśli nie jesteś pewien, jaka jest przyczyna zmiany, prawdopodobnie powinieneś założyć, że jest ostatnią na liście.

Jak OpenSSH obsługuje nieznane hosty

OpenSSH ma ustawienie jak obsługuje nieznane hosty, odzwierciedlone w zmiennej "StrictHostKeyChecking" (bez cudzysłowów).

W zależności od konfiguracji połączenia SSH z nieznanymi hostami (których klucze nie znajdują się już w pliku known_hosts) mogą być podzielone 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 niezabezpieczone i niezalecane, z wyjątkiem sytuacji, gdy dodajesz kilka hostów po ponownej instalacji systemu operacyjnego, po czym to zmienisz.
StrictHostKeyChecking jest ustawiony na pytanie; OpenSSH pokaże ci nowe klucze hosta i poprosi o potwierdzenie przed ich dodaniem. Zapobiega to przechodzeniu połączeń do zmienionych kluczy hosta. Jest to ustawienie domyślne.
StrictHostKeyChecking jest ustawiony na tak; Przeciwieństwo "nie" uniemożliwi połączenie się z dowolnym hostem, który nie jest już obecny w pliku known_hosts.

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

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

Zastąp [opcja] "nie", "zapytaj" lub "tak". Pamiętaj, że istnieją pojedyncze proste cytaty otaczające tę zmienną i jej ustawienie. Zamień również użytkownika @ host na nazwę użytkownika i nazwę hosta serwera, z którym się łączysz. Na przykład:

ssh -o 'StrictHostKeyChecking ask' [email protected]

Zablokowane hosty ze względu na zmiany kluczy

Jeśli masz serwer, do którego próbujesz uzyskać dostęp, a jego klucz już się zmienił, domyślna konfiguracja OpenSSH uniemożliwi ci dostęp do niego. Możesz zmienić wartość StrictHostKeyChecking dla tego hosta, ale to nie byłoby całkowicie, dokładnie, paranoidalnie bezpieczne, prawda? Zamiast tego możemy po prostu usunąć nieprawidłową wartość z naszego pliku known_hosts.

To zdecydowanie brzydka rzecz na ekranie. Na szczęście naszym powodem był ponownie zainstalowany system operacyjny. Teraz powiększmy potrzebną linię.

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

Oto nasz obraziący klucz, w linii 1. Wszystko, co musimy zrobić, to nacisnąć Ctrl + K, aby wyciąć całą linię.

Tak jest dużo lepiej! Teraz wciskamy Ctrl + O, aby wypisać (zapisać) plik, a następnie Ctrl + X, aby zakończyć.

Teraz dostajemy fajny monit, na który możemy po prostu odpowiedzieć "tak".

Tworzenie nowych kluczy hosta

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

Najpierw przejdź do odpowiedniego katalogu systemowego:

cd / etc / ssh /

Zazwyczaj 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ź 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 powiedzieć serwerowi OpenSSH, aby ponownie się skonfigurował:

sudo dpkg-reconfigure openssh-server

Pojawi się monit, gdy komputer utworzy nowe klucze. Ta-da!

Teraz, kiedy już wiesz, jak działa SSH, powinieneś być w stanie wydostać się z trudnych miejsc. Ostrzeżenie / błąd "Zdalna identyfikacja hosta zmieniła się" to coś, co wyrzuca wielu użytkowników, nawet tych, którzy znają linię poleceń.