Wielokrotnie wychwalaliśmy zalety SSH, zarówno pod względem bezpieczeństwa, jak i zdalnego dostępu. Przyjrzyjmy się samemu serwerowi, niektórym ważnym aspektom związanym z konserwacją i niektórym dziwactwom, 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 przez Cygwin .
Dlaczego to jest bezpieczne
Wielokrotnie wspominaliśmy, że SSH to świetny sposób na bezpieczne łączenie i tunelowanie danych z jednego punktu do drugiego. Przyjrzyjmy się bardzo krótko, jak to wszystko działa, aby lepiej zrozumieć, dlaczego czasami może być dziwnie.
Decydując się na zainicjowanie połączenia z innym komputerem często używamy protokołów, z którymi łatwo się pracuje. Przychodzą na myśl zarówno Telnet, jak i FTP. Wysyłamy informacje do zdalnego serwera, a następnie otrzymujemy potwierdzenie połączenia. Aby ustanowić pewien rodzaj bezpieczeństwa, protokoły te często używają kombinacji nazwy użytkownika i hasła. To oznacza, że są całkowicie bezpieczne, prawda? Źle!
Jeśli myślimy o naszym procesie łączenia się jako o poczcie, to używanie FTP, Telnetu i tym podobnych nie jest jak używanie standardowych kopert pocztowych. To bardziej przypomina pocztówki. Jeśli ktoś stanie w środku, będzie mógł 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. Nazywa się to atakiem „man-in-the-middle” i nie tylko naraża Twoje konto, ale także poddaje w wątpliwość 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, które zapewnia większe bezpieczeństwo HTTP. Tutaj mamy urząd pocztowy, który obsługuje korespondencję, który sprawdza, czy odbiorca jest tym, za kogo się podaje, i posiada przepisy chroniące Twoją pocztę przed przeglądaniem. Jest ogólnie bezpieczniejszy, a organ centralny - Verisign, w naszym przykładzie HTTPS - upewnia się, że osoba, do której wysyłasz pocztę, wyewidencjonowuje. Robią to, nie zezwalając na pocztówki (niezaszyfrowane dane uwierzytelniające); zamiast tego nakazują prawdziwe koperty.
Na koniec spójrzmy na SSH. Tutaj konfiguracja jest nieco inna. Nie mamy tutaj centralnego uwierzytelniacza, ale wszystko jest nadal bezpieczne. Dzieje się tak, ponieważ wysyłasz listy do osoby, której adres już znasz - powiedzmy, rozmawiając z nią przez telefon - i używasz naprawdę wymyślnej matematyki do podpisania koperty. Przekazujesz go swojemu bratu, dziewczynie, tacie lub córce, aby zabrał go pod wskazany adres, i tylko wtedy, gdy wyszukane matematyki odbiorcy są zgodne, zakładasz, że adres jest właściwy. Następnie otrzymujesz list z powrotem, również chroniony przed wzrokiem ciekawskich dzięki tej niesamowitej matematyce. Na koniec wysyłasz swoje dane uwierzytelniające w innej tajnej kopercie zaczarowanej algorytmicznie 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 uda nam się go tam wyciąć. Jeśli masz więcej wglądu, możesz oczywiście porozmawiać w komentarzach. Na razie jednak przyjrzyjmy się najważniejszej funkcji SSH - uwierzytelnianiu hostów.
Klucze hosta
Uwierzytelnianie hosta to zasadniczo ta część, w której osoba, której ufasz, 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 można z tego usunąć:
- Ponieważ nie ma organu centralnego, prawdziwe bezpieczeństwo leży w kluczu hosta, kluczach publicznych i kluczach prywatnych. (Te dwa ostatnie klucze są konfigurowane po uzyskaniu dostępu do systemu).
- Zwykle podczas łączenia się z innym komputerem za pośrednictwem protokołu SSH klucz hosta jest przechowywany. Dzięki temu przyszłe działania są szybsze (lub mniej szczegółowe).
- 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, przed połączeniem należy sprawdzić klucz. Zobaczysz okno dialogowe potwierdzenia, jak poniżej.
Nie powinieneś się jednak martwić! Często, gdy problemem jest bezpieczeństwo, istnieje specjalne miejsce, w którym można potwierdzić klucz hosta (powyżej odcisk palca ECDSA). W przedsięwzięciach całkowicie online często będzie to bezpieczna witryna umożliwiająca logowanie. 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 niektórych miejscach, w których klucz znajduje się na 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 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 ). Skoncentrujemy 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 ца: 62: еа: щц: еч: яй: 2е: аш: яч: 20: 11: дб: яц: 78: цз: чц /етц/сш/сш_хост_ецдса_кей.пуб
Pierwsza liczba to długość w bitach klucza, następnie sam klucz, a na końcu masz plik, w którym jest on przechowywany. Porównaj tę środkową część z tym, co widzisz, gdy zostanie wyświetlony monit o zdalne zalogowanie. Powinien pasować i gotowe. Jeśli tak się nie stanie, może się wydarzyć coś innego.
Możesz wyświetlić wszystkie hosty, z którymi połączyłeś się przez SSH, patrząc na swój plik known_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ą przechowywane z nazwą (lub adresem internetowym) komputera-hosta i jego adresem IP.
Zmiana kluczy hosta i problemów
Istnieje kilka powodów, dla których zmieniają się klucze hosta lub nie pasują do tego, co jest zapisane w pliku znane_hosts.
- System został ponownie zainstalowany / skonfigurowany.
- Klucze hosta zostały zmienione ręcznie 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.
- Dzierżawa adresu IP lub DNS uległa zmianie. Często oznacza to, że próbujesz uzyskać dostęp do innego komputera.
- System został w jakiś sposób przejęty, tak ż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 wystąpić problem z serwerem i możesz zostać przekierowany na inną maszynę. Jeśli nie masz pewności, jaki jest powód zmiany, prawdopodobnie powinieneś założyć, że jest to ostatnia pozycja na liście.
Jak OpenSSH obsługuje nieznane hosty
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órych kluczy nie ma jeszcze w pliku znane_hosts) mogą przebiegać na trzy sposoby.
- StrictHostKeyChecking jest ustawiona na no; OpenSSH automatycznie połączy się z dowolnym serwerem SSH, niezależnie od stanu klucza hosta. Jest to niezabezpieczone i niezalecane, z wyjątkiem sytuacji, gdy dodajesz kilka hostów po ponownej instalacji systemu operacyjnego, po czym ponownie je zmienisz.
- StrictHostKeyChecking jest ustawiony na zapytanie; OpenSSH pokaże Ci nowe klucze hosta i poprosi o potwierdzenie przed ich dodaniem. Zapobiegnie to przechodzeniu połączeń do zmienionych kluczy hosta. To jest ustawienie domyślne.
- StrictHostKeyChecking jest ustawiona na tak; W przeciwieństwie do „nie”, zapobiegnie to połączeniu się z dowolnym hostem, którego nie ma w pliku znane_hosts.
Możesz łatwo zmienić tę zmienną w wierszu poleceń, używając następującego paradygmatu:
ssh -o 'StrictHostKeyChecking [option]' user @ host
Zastąp [option] słowami „nie”, „zapytaj” lub „tak”. Należy pamiętać, że zmienną i jej ustawienie otaczają pojedyncze cudzysłowy. Zastąp również 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 zmiany kluczy
Jeśli masz serwer, do którego próbujesz uzyskać dostęp, a jego klucz został już zmieniony, domyślna konfiguracja OpenSSH uniemożliwi dostęp do niego. Możesz zmienić wartość StrictHostKeyChecking dla tego hosta, ale nie byłoby to całkowicie, całkowicie i paranoidalnie bezpieczne, prawda? Zamiast tego możemy po prostu usunąć obraźliwą wartość z naszego pliku known_hosts.
To zdecydowanie brzydka rzecz na ekranie. Na szczęście naszym powodem była ponowna instalacja systemu operacyjnego. Więc powiększmy linię, której potrzebujemy.
No to jedziemy. Widzisz, jak cytuje plik, który musimy edytować? Daje nam nawet numer linii! A więc otwórzmy ten plik w Nano:
Oto nasz obraźliwy klucz w linii 1. Wszystko, co musimy zrobić, to nacisnąć Ctrl + K, aby wyciąć całą linię.
To jest o wiele lepsze! Więc teraz wciskamy Ctrl + O, aby wypisać (zapisać) plik, a następnie Ctrl + X, aby wyjść.
Teraz zamiast tego otrzymujemy fajny monit, na który możemy po prostu odpowiedzieć „tak”.
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 łatwo zrobić.
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 mają 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 sam się zrekonfigurował:
sudo dpkg-reconfigure openssh-server
Gdy komputer utworzy nowe klucze, pojawi się monit. Ta-da!
Teraz, gdy już wiesz, jak działa SSH, powinieneś być w stanie wydostać się z trudnych sytuacji. Ostrzeżenie / błąd „Zmieniła się identyfikacja zdalnego hosta” jest czymś, co wytrąca z równowagi wielu użytkowników, nawet tych, którzy znają wiersz poleceń.
Aby uzyskać punkty bonusowe, możesz sprawdzić Jak zdalnie kopiować pliki przez SSH bez podawania hasła . Dowiesz się tam trochę więcej o innych rodzajach algorytmów szyfrowania oraz o tym, jak używać plików kluczy w celu zwiększenia bezpieczeństwa.
