Co to jest protokół SSH (Secure Shell) i do czego służy?

Protokół SSH (Secure Shell) to kryptograficzny standard komunikacji sieciowej, który pozwala na bezpieczne, szyfrowane logowanie i zdalne zarządzanie serwerami przez niezabezpieczone sieci publiczne. Służy on przede wszystkim do wykonywania poleceń w terminalu, transferu plików oraz tunelowania ruchu, całkowicie zastępując przestarzałe metody wysyłające dane czystym tekstem. Odpowiedź na główne pytanie brzmi po prostu tak. Zabezpieczamy nim dostęp.

Pamiętam doskonale wdrożenie w pewnej firmie logistycznej w zeszłym roku. Główny administrator zostawił otwarty port 23 dla usługi Telnet, bo uważał to za wygodne rozwiązanie w wewnętrznej sieci LAN. Dwa dni później cała ich baza danych wyciekła na zewnątrz. Ktoś podpiął się pod switcha w sali konferencyjnej i podsłuchał ruch z użyciem zwykłego Wiresharka. Hasła szły w czystym tekście. Gdyby użyli SSH, atakujący zobaczyłby wyłącznie niezrozumiały ciąg zaszyfrowanych znaków. To jest właśnie absolutna podstawa działania Secure Shell. Odcina on intruzom możliwość podsłuchania transmisji.

Jak działa protokół SSH od strony technicznej?

Cały proces opiera się na architekturze klient-serwer. Maszyna docelowa uruchamia demona, czyli usługę działającą w tle. Nazywamy ją zazwyczaj sshd. Z kolei Ty, siedząc przed swoim laptopem, uruchamiasz klienta. Wpisujesz komendę w terminalu. Inicjujesz połączenie. I tu zaczyna się prawdziwa kryptografia.

Proces nawiązania sesji dzieli się na wyraźne etapy. Najpierw obie strony muszą ustalić, w jakiej wersji protokołu będą rozmawiać. Dzisiaj absolutnym standardem jest SSH-2. Jedynka miała błędy. Potem następuje wymiana algorytmów. Klient mówi, co potrafi obsłużyć, a serwer wybiera najsilniejszą opcję ze wspólnej puli. Następnie wchodzi algorytm wymiany kluczy, zazwyczaj oparty na krzywych eliptycznych lub metodzie Diffiego-Hellmana. Obie strony generują wspólny, tajny klucz sesji. Ten klucz jest symetryczny. Co to oznacza w praktyce administracyjnej? Używamy go do szyfrowania całej dalszej transmisji danych, bo algorytmy symetryczne są o wiele szybsze pod kątem obliczeniowym dla procesorów.

Tylko jak serwer ma pewność, że Ty to Ty? Do tego służy uwierzytelnianie.

Dlaczego port 22 to domyślny standard?

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze u skanerów sieciowych? Sam się nad tym borykałem dzisiaj u siebie we wtorek na jednym z wdrożeń. Prawda jest absolutnie taka, że port 22 został przypisany do usługi SSH w 1995 roku przez organizację IANA. Tatu Ylönen, twórca protokołu, po prostu o to poprosił. W tamtym czasie port 21 zajmował FTP, a 23 należał do Telnetu. Ylönen wbił się dokładnie w środek. Dzisiaj zmiana tego portu na inny, na przykład 2222 lub 49152, to pierwszy krok by ukryć maszynę przed amatorskimi botami skanującymi internet w poszukiwaniu otwartych furtek. Boty zazwyczaj uderzają w domyślne wartości. Zmiana portu nie poprawia samej kryptografii. Odcina jedynie masowy szum i odciąża logi systemowe.

Do czego służy protokół Secure Shell w codziennej pracy administratora?

Teoretycy powiedzą, że do bezpiecznej komunikacji. Praktycy z działów operacyjnych wiedzą swoje. SSH to narzędzie do wszystkiego. Bez niego współczesny internet po prostu by stanął. Zarządzamy nim serwerami VPS, routerami brzegowymi, a nawet malutkimi urządzeniami typu Raspberry Pi schowanymi w szafach sterowniczych na halach produkcyjnych.

Oto co naprawdę robimy z użyciem tego narzędzia każdego dnia:

• Wykonywanie poleceń w zdalnym systemie operacyjnym Linux lub Unix tak, jakbyśmy siedzieli fizycznie przed monitorem podpiętym do serwera w chłodnej serwerowni we Frankfurcie. Edytujemy pliki konfiguracyjne, restartujemy usługi, przeglądamy logi systemowe za pomocą komend grep i tail. Wszystko dzieje się w czasie rzeczywistym.
• Bezpieczny transfer plików.
• Zestawianie tuneli kryptograficznych omijających lokalne zapory sieciowe.
• Automatyzacja.

Widzisz asymetrię tej listy? O to właśnie chodzi w prawdziwej pracy. Zdarzają się dni, gdy tylko kopiujemy plik przez SCP. Innym razem siedzimy osiem godzin w konsoli.

Jak skonfigurować bezpieczne logowanie bez hasła?

Uwierzytelnianie za pomocą hasła to przeżytek. Ludzie używają słabych ciągów znaków. Maszyny potrafią je odgadnąć metodą brute-force w kilka dni. Prawie połowa włamań na małe serwery wynika z użycia słownikowych haseł. Dlatego przechodzimy na klucze asymetryczne.

Generujesz parę kluczy u siebie na komputerze lokalnym. Składa się ona z klucza prywatnego i publicznego. Prywatny zostaje na Twoim dysku. Pilnujesz go. Możesz dodatkowo nałożyć na niego hasło. Klucz publiczny wysyłasz na serwer i wrzucasz do pliku authorized_keys w katalogu ukrytym .ssh. Od tego momentu serwer wpuszcza Cię na podstawie dowodu matematycznego. Sprawdza, czy posiadasz klucz prywatny pasujący do publicznego zamka. Nie przesyłacie sobie żadnych haseł przez sieć. Wtedy na ekranie pojawia się KRYTYCZNY błąd odmowy dostępu u każdego, kto próbuje wejść na tradycyjne poświadczenia, o ile wyłączysz taką opcję w pliku sshd_config.

Kiedy tunelowanie SSH i przekierowanie portów ratuje sytuację na produkcji?

Wyobraź sobie sytuację. Siedzisz w hotelu na delegacji. Musisz pilnie podłączyć się do bazy danych PostgreSQL, która stoi w firmowej infrastrukturze. Baza jest odcięta od świata zewnętrznego. Słucha tylko na interfejsie lokalnym localhost. Z zewnątrz dostępny jest jedynie serwer przesiadkowy, tak zwany bastion, na którym działa usługa SSH. Co robisz?

Zestawiasz tunel lokalny. Wpisujesz odpowiednią komendę z flagą -L. Twój lokalny klient SSH otwiera port na Twoim laptopie, na przykład 5432, i szyfruje cały ruch, ładując go w paczki. Te paczki wędrują do bastionu. Bastion je rozszyfrowuje i przekazuje czystym tekstem do bazy danych wewnątrz bezpiecznej sieci LAN. Twój lokalny program do obsługi bazy myśli, że łączy się z bazą na Twoim własnym komputerze. To jest właśnie port forwarding.

Jak stwierdził w zeszłym miesiącu starszy inżynier bezpieczeństwa z polskiego oddziału pewnego banku: Szyfrowane tunele to nasze koło ratunkowe, bez nich praca zdalna z systemami krytycznymi wymagałaby ociężałych i drogich klientów VPN do każdej prostej operacji na bazie.

Mamy trzy rodzaje takiego przekierowania. Lokalne, zdalne i dynamiczne. Zdalne pozwala wystawić Twoją lokalną usługę na publiczny adres serwera. Dynamiczne z kolei tworzy z Twojego połączenia SSH pełnoprawny serwer proxy SOCKS. Podpinasz pod to przeglądarkę internetową i cały Twój ruch webowy wychodzi na świat z adresu IP serwera docelowego. Omijasz w ten sposób lokalne blokady nałożone przez administratora sieci w kawiarni czy na uczelni.

Telnet vs SSH – dlaczego ten pierwszy musiał zniknąć z rynku?

Dawniej sieci były małe i ufne. Uczelnie łączyły się ze sobą. Nikt nie myślał o cyberprzestępczości. W takich warunkach powstał Telnet. Robił dokładnie to samo co Secure Shell. Dawał dostęp do powłoki. Miał jednak jedną, dyskwalifikującą wadę z punktu widzenia współczesnego internetu. Brak szyfrowania.

Przesiadka była bolesna, ale konieczna. Wymagała od administratorów nauki zarządzania nowym typem poświadczeń. Dzisiaj nikt o zdrowych zmysłach nie instaluje demona Telnet na serwerze wystawionym do sieci publicznej. To po prostu proszenie się o kłopoty. Znalezienie otwartego portu 23 przez skaner Shodan zajmuje botom około czterech minut od momentu podpięcia maszyny do internetu.

Szyfrowanie symetryczne a asymetryczne podczas nawiązywania sesji

(Nawiasem mówiąc, wiele osób myli te dwa pojęcia, kupując tanie klawiatury mechaniczne i skupiając się na kliku przełączników, zamiast uczyć się fundamentów sieci. Sam używam starych przełączników Cherry MX Blue, bo lubię hałas podczas pisania skryptów w Bashu, ale wracając do tematu). Asymetryczna kryptografia jest ciężka. Serwer i klient używają jej tylko przez pierwsze kilkadziesiąt milisekund. Wymieniają się materiałem kryptograficznym. Weryfikują swoje tożsamości. Kiedy ustalą już wspólny klucz, porzucają matematykę asymetryczną na rzecz symetrycznej. Szyfry takie jak AES-GCM lub ChaCha20-Poly1305 wkraczają do gry. Są one sprzętowo akcelerowane przez nowoczesne procesory. Dzięki temu pobieranie ogromnego pliku z logami nie zabija rdzeni procesora na serwerze.

Jakie są najczęstsze błędy i luki bezpieczeństwa w konfiguracji demona SSHD?

Instalacja usługi z repozytorium to pikuś. Utrzymanie jej bezpieczeństwa to już inna para kaloszy. Zostawienie domyślnej konfiguracji to błąd początkujących. Plik konfiguracyjny leży zazwyczaj w /etc/ssh/sshd_config. To tam decydujesz o być albo nie być Twojej maszyny.

Główne grzechy administratorów to brak wyłączenia logowania na konto root. Użytkownik root ma absolutną władzę. Jeśli atakujący odgadnie jego hasło, gra jest skończona. Dobra praktyka to logowanie na zwykłego użytkownika z ograniczonymi prawami, a następnie użycie komendy sudo do podniesienia uprawnień po podaniu drugiego hasła. Inną usterką jest zostawienie włączonego uwierzytelniania opartego na pustych hasłach. Dyrektywa PermitEmptyPasswords zawsze musi mieć wartość „no”.

Często widzę też brak mechanizmów opóźniających ataki. Fail2ban to proste narzędzie. Analizuje logi systemowe. Jeśli widzi, że ktoś z danego adresu IP podał złe hasło pięć razy z rzędu, wrzuca ten adres do zapory iptables i banuje na godzinę. Zwykła instalacja i uruchomienie tego małego demona odcina 99 procent zautomatyzowanego syfu z sieci.

Czy klucze RSA nadal wystarczają, czy musimy przejść na Ed25519?

Kryptografia się starzeje. To naturalny proces. Komputery stają się szybsze. Algorytmy, które wczoraj uchodziły za bezpieczne, dzisiaj łamie się w kilka dni za pomocą farm kart graficznych. RSA to weteran. Działa na zasadzie trudności faktoryzacji wielkich liczb pierwszych. Klucz RSA o długości 2048 bitów to dzisiaj absolutne minimum. Prawdę mówiąc, wiele instytucji finansowych wymusza już 4096 bitów.

Ale tu pojawia się problem. Klucze 4096-bitowe są długie. Generowanie podpisów zajmuje czas. Dlatego społeczność IT przeszła na krzywe eliptyczne. Algorytm Ed25519 to obecnie złoty standard. Klucz jest krótki. Mieści się w jednej linijce. Jest odporny na znane ataki kryptograficzne, a jego generowanie obciąża procesor w minimalnym stopniu. Jeśli dzisiaj tworzysz nowe poświadczenia dostępu, wpisz po prostu ssh-keygen -t ed25519. Zostaw staruszka RSA w spokoju, chyba że łączysz się ze sprzętem sieciowym sprzed dekady, który nie obsługuje nowszych standardów.

Zarządzanie uprawnieniami i plik authorized_keys

Wrzucenie klucza publicznego na serwer to początek. Musisz zadbać o prawa dostępu do plików w systemie Linux. Demon sshd jest bardzo rygorystyczny. Jeśli zobaczy, że Twój katalog .ssh ma prawa odczytu dla wszystkich użytkowników w systemie, po prostu zablokuje możliwość logowania z użyciem klucza. Zrobi to bez ostrzeżenia na ekranie klienta. Katalog musi mieć uprawnienia 700. Plik z kluczami uprawnienia 600. Zmieniliśmy te zasady na robocie lata temu, a ludzie ciągle o tym zapominają, tracąc godziny na debugowanie logów auth.log.

Zabezpieczanie dostępu do serwera VPS krok po kroku

Kupiłeś tanią maszynę w chmurze. Chcesz na niej postawić bloga, serwer gry albo własną chmurę na pliki. Dostajesz adres IP i hasło do roota na maila. Co robisz w pierwszej kolejności?

• Logujesz się tymczasowo jako root. Zakładasz nowego użytkownika komendą useradd. Dodajesz go do grupy sudo. Testujesz, czy nowy użytkownik faktycznie może podnieść swoje uprawnienia. Przelogowujesz się na niego.
• Generujesz klucz Ed25519 na swoim laptopie.
• Wrzucasz klucz za pomocą komendy ssh-copy-id.
• Otwierasz edytor nano. Wchodzisz do sshd_config. Wyłączasz PermitRootLogin. Wyłączasz PasswordAuthentication. Zmieniasz port z 22 na 55432. Zapisujesz. Robisz restart usługi systemctl restart sshd.

Zostawiasz otwartą obecną sesję. Otwierasz drugie okno terminala i próbujesz wbić się na nowo. Jeśli popełniłeś błąd w konfiguracji, stara sesja uratuje Ci dostęp. Jeśli wszystko działa po kluczu na nowym porcie, zamykasz pierwszą sesję. Maszyna jest zabezpieczona przed przypadkowym włamaniem. To jest bez mała najgorsza opcja z wszystkich, by zostawić serwer zaraz po zakupie z konfiguracją od dostawcy hostingu.

Gdzie protokół SSH zawodzi i jak radzić sobie z zerwanymi sesjami

Protokół ten opiera się na TCP. To protokół połączeniowy. Wymaga stałego połączenia między klientem a serwerem. Jeśli jedziesz pociągiem i Twoje połączenie komórkowe przełączy się między nadajnikami, zmienisz adres IP. Połączenie TCP zostanie brutalnie zerwane. Terminal zamarznie. Musisz zabić klienta i łączyć się od nowa.

To irytuje. Szczególnie gdy kompilujesz duży program albo aktualizujesz system. Rozwiązaniem na poziomie serwera są multipleksery terminala, takie jak tmux lub screen. Uruchamiasz tmuxa po zalogowaniu. Tworzy on wirtualną sesję. Odpalasz aktualizację. Jeśli zerwie Ci połączenie, demon sshd zabije Twój proces logowania, ale tmux utrzyma procesy w tle. Łączysz się ponownie, wpisujesz tmux attach i wracasz dokładnie w to samo miejsce. Ekran odświeża się natychmiast.

Innym podejściem jest użycie alternatywy takiej jak Mosh (Mobile Shell). Mosh używa UDP. Synchronizuje stan ekranu między klientem a serwerem. Zmieniasz sieć z Wi-Fi na LTE? Mosh po prostu wznawia komunikację w ułamku sekundy bez zrywania powłoki. Wymaga jednak otwarcia szerokiego zakresu portów UDP na zaporze, co w restrykcyjnych środowiskach korporacyjnych bywa blokowane przez działy sieciowe.

Zaloguj się teraz na swój serwer. Sprawdź logi w /var/log/auth.log. Zobacz ile chińskich i rosyjskich adresów IP próbuje odgadnąć Twoje hasło w tej właśnie sekundzie. Zmień port. Skonfiguruj klucze. Zbanuj ich ruch na firewallu. Skrypty automatyzujące nie zrobią tego za Ciebie, dopóki sam nie zrozumiesz mechaniki stojącej za warstwą kryptograficzną.

Bibliografia

1. CERT Polska – https://cert.pl
2. Internet Engineering Task Force – https://www.ietf.org
3. NASK Państwowy Instytut Badawczy – https://www.nask.pl
4. OpenSSH Project – https://www.openssh.com
5. Fundacja Bezpieczna Cyberprzestrzeń – https://www.cybsecurity.org