Wielokrotnie wychwalaliśmy zalety SSH, zarówno dla bezpieczeństwa, jak i zdalnego dostępu. Przyjrzyjmy się samemu serwerowi, niektórym ważnym aspektom "konserwacji" 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.
Wielokrotnie wspominaliśmy, jak SSH to świetny sposób na bezpieczne łączenie i tunelowanie danych z jednego punktu do drugiego. Przyjrzyjmy się bardzo krótko, jak działają, 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 na temat naszego połączenia. 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 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 tzw. Atak typu "man-in-the-middle", który 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 pomiędzy.
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ę, wyewidencjonuje. 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ć. Potem 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, myślimy, ż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.
Uwierzytelnianie hosta to w zasadzie część, w której osoba, której ufasz, przyjmuje kopertę (zapieczętowana za pomocą magicznej matematyki) i potwierdza adres odbiorcy. Jest to dość szczegółowy opis adresu i opiera się na skomplikowanej matematyce, którą pominiemy. Jest jednak kilka ważnych rzeczy do usunięcia:
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ć!
Istnieją 4 typy algorytmów szyfrowania używanych do tworzenia kluczy, ale domyślną wartością dla OpenSSH na początku tego roku jest 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 tę środkową 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ą przechowywane wraz z nazwą komputera (lub adresem WWW) hosta i jego adresem IP.
Istnieje kilka powodów, dla których klucze hosta się zmieniają lub nie pasują do tego, co jest zapisane w pliku known_hosts.
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ż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.
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ć wykonywane na trzy sposoby.
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. Również zamień 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]
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ąć szkodliwą wartość z naszego pliku known_hosts.
To zdecydowanie brzydka rzecz na ekranie. Na szczęście naszym powodem było ponowne zainstalowanie systemu operacyjnego. Więc powiększmy linię, której potrzebujemy.
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".
Dla przypomnienia, naprawdę nie ma 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 /
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ę" jest czymś, co wyrzuca wielu użytkowników, nawet tych, którzy znają linię poleceń.
Aby uzyskać punkty bonusowe, możesz zapoznać się z artykułem Jak zdalnie kopiować pliki przez SSH bez podawania hasła. Tam dowiesz się trochę więcej o innych rodzajach algorytmów szyfrowania i jak korzystać z plików kluczy, aby zwiększyć bezpieczeństwo.
