Co to jest OpenSSH i jak go używać do bezpiecznych połączeń zdalnych?

OpenSSH to zestaw narzędzi sieciowych opartych na protokole Secure Shell, służący do szyfrowanego logowania, przesyłania plików i wykonywania poleceń na odległych maszynach. Używa się go poprzez wywołanie klienta w terminalu i nawiązanie zaszyfrowanego kanału z serwerem nasłuchującym, co chroni dane przed podsłuchem w niezaufanych sieciach. Administratorzy systemów operacyjnych z rodziny Linux i Unix opierają na tym rozwiązaniu całą codzienną pracę. Oprogramowanie to zastąpiło przestarzałe i dziurawe protokoły Telnet oraz rlogin. Prawda jest zresztą absolutnie taka, że nikt przy zdrowych zmysłach nie puszcza dzisiaj ruchu w sieci czystym tekstem.

Zasada działania opiera się na architekturze klient-serwer. Uruchamiasz proces demona sshd na maszynie docelowej. Demon nasłuchuje żądań. Na swoim laptopie odpalasz komendę ssh. Następuje negocjacja algorytmów szyfrujących, wymiana kluczy sesyjnych i uwierzytelnienie użytkownika. Wszystko dzieje się w ułamku sekundy. Pakiety krążą bezpiecznie. Podglądacz z wpiętym snifferem widzi tylko losowy szum.

Dlaczego w ogóle musimy szyfrować ruch w sieci?

Kiedyś sieci lokalne uważano za bezpieczne strefy. Użytkownicy logowali się do serwerów wpisując hasła, które leciały kablem bez żadnej osłony. Wystarczyło uruchomić prosty program do przechwytywania pakietów na dowolnym komputerze wpiętym w ten sam switch. Hasła wypadały na ekran jak na tacy. Zmiana nadeszła, gdy ataki man-in-the-middle stały się bolesną codziennością w akademikach i biurach.

OpenSSH rozwiązuje ten problem u samej podstawy. Wymusza szyfrowanie od końca do końca. Zanim wyślesz chociażby jeden znak ze swojego terminala, maszyny ustalają bezpieczny kanał komunikacji. Wykorzystują do tego matematykę. Konkretnie kryptografię asymetryczną do wymiany klucza symetrycznego, którym potem szyfrują właściwą transmisję. To proste. To działa.

Pamiętam wdrożenie na warszawskim Mokotowie u jednego z klientów jesienią 2022 roku. Wpięliśmy serwer wystawiony publicznie na zewnątrz. W logach od razu pojawił się szum. Chińskie i rosyjskie botnety uderzyły w port 22 w ciągu dosłownie czternastu sekund od podniesienia interfejsu sieciowego. Skanery szukały słabych haseł root. Gdybyśmy użyli Telnetu, maszyna padłaby do wieczora. Z OpenSSH i wyłączonym logowaniem na hasło, ataki odbijały się od ściany. Zmarnowali tylko swój prąd.

Jak działa logowanie z użyciem kluczy zamiast hasła?

Tradycyjne hasła mają ogromną wadę. Ludzie je zgadują. Słownikowe ataki brute-force mielą terabajty kombinacji w poszukiwaniu jednego trafienia. Klucze kryptograficzne eliminują czynnik ludzki. Zamiast wymyślać ciąg znaków, generujesz plik matematyczny. Tworzysz parę: klucz prywatny i klucz publiczny.

Klucz publiczny wrzucasz na serwer. Możesz go pokazać każdemu. Nie ma w nim żadnej tajemnicy. Klucz prywatny trzymasz na swoim dysku i pilnujesz go jak oka w głowie. Kiedy próbujesz się połączyć, serwer rzuca ci wyzwanie matematyczne. Tylko posiadacz klucza prywatnego potrafi je rozwiązać. Jeśli wynik się zgadza, wchodzisz. Serwer nigdy nie widzi twojego klucza prywatnego. Nie przesyłasz go przez sieć.

Generowanie pary kluczy asymetrycznych krok po kroku

Porzuć stare algorytmy RSA. Są wolne i wymagają długich ciągów bitów by zapewnić bezpieczeństwo. Obecnie standardem jest krzywa eliptyczna Ed25519. Daje krótkie pliki i niezwykle mocną ochronę. Otwierasz terminal i wpisujesz jedno polecenie. Żadnej filozofii.

• Wpisz komendę ssh-keygen -t ed25519 -C „[email protected]” i wciśnij enter. System zapyta o ścieżkę zapisu. Zostaw domyślną. Następnie poprosi o hasło do samego klucza. Zawsze podawaj passphrase. Jeśli ktoś ukradnie ci laptopa, sam plik na nic mu się nie przyda bez tego dodatkowego pinu.
• Skopiuj klucz na serwer.
• Gotowe.
• Użyj narzędzia ssh-copy-id user@adres_ip. Program sam dopisze twój klucz publiczny do pliku authorized_keys na maszynie docelowej. Od tej pory serwer wpuści cię bez pytania o hasło systemowe.

Wielu początkujących administratorów gubi się w uprawnieniach plików. Serwer OpenSSH jest na tym punkcie paranoiczny. Jeśli katalog .ssh na serwerze ma uprawnienia pozwalające na zapis przez innych użytkowników, demon po prostu odrzuci twoje żądanie logowania. Ustaw chmod 700 na katalog i chmod 600 na plik authorized_keys. Inaczej będziesz szukać błędu przez pół dnia.

W jaki sposób skonfigurować serwer by odciąć ataki z zewnątrz?

Domyślna konfiguracja instalowana z pakietów w Debianie czy Ubuntu działa, ale zostawia wiele otwartych drzwi. Fabryczne ustawienia pozwalają na logowanie hasłem. Pozwalają też zalogować się bezpośrednio na konto głównego administratora, czyli roota. To absolutny błąd w sztuce.

Plik konfiguracyjny znajdziesz w /etc/ssh/sshd_config. Otwierasz go w edytorze nano lub vim. Szukasz linii PermitRootLogin. Zmieniasz wartość na no. Od teraz nikt nie wejdzie z uprawnieniami superużytkownika wprost z internetu. Trzeba zalogować się na zwykłe konto i dopiero z niego podnieść uprawnienia komendą sudo. To urywa łeb większości zautomatyzowanych skryptów atakujących w sieci.

Wyłączasz uwierzytelnianie hasłem. Znajdź PasswordAuthentication i wstaw no. W tym momencie logowanie z użyciem kluczy staje się jedyną dostępną metodą. Upewnij się tylko dwa razy, że twój klucz publiczny faktycznie leży na serwerze i działa, bo inaczej odetniesz sam siebie od własnej maszyny. Zrobiliśmy tak kiedyś na wdrożeniu w 2018 roku. Ktoś zrestartował usługę przed testem kluczy. Trzeba było jechać do serwerowni fizycznie z monitorem pod pachą.

Zmiana domyślnego portu 22 i ograniczanie dostępu

Port 22 to domyślne drzwi wejściowe. Każdy skaner w internecie w pierwszej kolejności puka właśnie tam. Zmiana tego portu na wyższy, na przykład 52222, nie jest żadnym zabezpieczeniem kryptograficznym. To zwykłe zaciemnianie obrazu. Security through obscurity. Mimo to, warto to zrobić. Ogranicza to ilość śmieci w logach systemowych o bez mała dziewięćdziesiąt procent. Zmieniasz dyrektywę Port w pliku konfiguracyjnym, restartujesz usługę i gotowe.

Zastosuj też dyrektywę AllowUsers. Jeśli na serwerze masz pięćdziesiąt kont systemowych, a tylko dwóch administratorów potrzebuje dostępu zdalnego, po co pozwalać reszcie na próby logowania? Wpisujesz AllowUsers admin1 admin2. Reszta załogi dostanie odmowę jeszcze przed rozpoczęciem negocjacji kryptograficznej. Krótka piłka.

Do czego służy tunelowanie i przekierowanie portów?

OpenSSH to nie tylko terminal. To potężne narzędzie do przesyłania dowolnego ruchu sieciowego wewnątrz zaszyfrowanej rury. Wyobraź sobie, że masz w biurze serwer bazodanowy. Ze względów bezpieczeństwa baza nasłuchuje tylko na interfejsie lokalnym localhost. Ty siedzisz z laptopem w kawiarni i musisz wykonać zapytanie SQL. Tutaj wkracza Local Port Forwarding.

Uruchamiasz komendę, która otwiera port na twoim laptopie i mówi klientowi SSH: cokolwiek wpadnie w ten port, przepchnij to zaszyfrowanym kanałem do serwera, a po drugiej stronie wypluj to prosto do bazy danych. Aplikacja kliencka na twoim komputerze myśli, że łączy się z bazą lokalnie. Sieć widzi tylko zaszyfrowany ruch SSH.

Różnica między opcjami jest prosta. Flaga -L ciągnie usługę z serwera do ciebie. Flaga -R wypycha twoją lokalną usługę na zdalny serwer. Używałem tego drugiego rozwiązania, gdy pisałem kod aplikacji w pociągu i chciałem pokazać działającą stronę klientowi. Wystawiłem port z mojego laptopa na publiczny serwer w chmurze. Klient wpisał adres IP serwera w przeglądarkę i widział aplikację odpaloną z mojego dysku. NIGDY nie zostawiaj takich tuneli odpalonych na noc bez nadzoru. Zamykasz sesję, zamykasz dziurę.

Jak zarządzać połączeniami przez plik konfiguracyjny klienta?

Kiedy masz pod opieką trzy serwery, pamiętasz ich adresy IP. Kiedy masz ich trzydzieści, zaczyna się dramat. Wpisywanie ciągów typu ssh -i ~/.ssh/klucz_produkcja -p 2244 [email protected] to marnowanie czasu. Klient OpenSSH posiada mechanizm aliasów. Plik ~/.ssh/config po stronie twojego komputera to centrum dowodzenia.

Tworzysz blok tekstowy. Nazywasz hosta krótko, na przykład „prod-web”. Pod spodem definiujesz HostName, User, Port i IdentityFile. Od tego momentu w terminalu wpisujesz po prostu ssh prod-web. Klient sam wczytuje resztę parametrów i nawiązuje połączenie. To ratuje życie podczas awarii o trzeciej nad ranem, kiedy palce nie trafiają w klawiaturę ze zmęczenia.

W pliku config można też definiować skoki przez maszyny pośredniczące. Opcja ProxyJump pozwala połączyć się z serwerem, który jest schowany głęboko w sieci prywatnej, pod warunkiem, że mamy dostęp do serwera brzegowego nazywanego bastionem. Definiujesz bastion. Definiujesz cel i wskazujesz, że do celu idziesz przez bastion. Klient SSH sam odpala podwójny tunel. Siedzisz u siebie, a w terminalu od razu lądujesz na maszynie wewnętrznej. Bez ręcznego logowania się dwa razy.

Ochrona kluczy sprzętowych i agent SSH

Trzymanie kluczy prywatnych na dysku to pewne ryzyko. Złośliwe oprogramowanie potrafi wyciągnąć pliki z katalogu domowego. Odpowiedzią branży na ten problem jest integracja ze sprzętowymi kluczami bezpieczeństwa FIDO2, takimi jak YubiKey. OpenSSH obsługuje je natywnie. Wymaga to typu klucza ecdsa-sk lub ed25519-sk. Sk oznacza secure key.

Generujesz klucz, ale materiał kryptograficzny ląduje na chipie w pendrive, a nie na dysku laptopa. Kiedy próbujesz się połączyć, serwer prosi o podpisanie żądania. Twój YubiKey zaczyna migać. Dopóki nie dotkniesz go fizycznie palcem, operacja nie pójdzie dalej. Nawet jeśli ktoś przejmie twój komputer przez trojana, nie zaloguje się nigdzie, bo nie ma fizycznego dostępu do sprzętu na twoim biurku. Wdrożyliśmy to u siebie na dziale w zeszłym kwartale. Zero incydentów.

Z kolei ssh-agent to mały program działający w tle na twoim systemie. Wczytujesz do niego swój klucz prywatny raz, wpisujesz hasło, a agent trzyma go w pamięci operacyjnej w formie zdekodowanej. Przy każdym kolejnym połączeniu klient SSH pyta agenta o potwierdzenie tożsamości. Nie musisz wpisywać hasła do klucza co pięć minut. Kiedy wylogowujesz się z systemu, pamięć jest czyszczona. Wygoda i bezpieczeństwo w jednym kawałku kodu.

Jakie są najczęstsze błędy podczas wdrażania OpenSSH w firmie?

Błędy wynikają z lenistwa. Administratorzy zostawiają stare wersje pakietów. Luki w demonie sshd zdarzają się rzadko, ale kiedy już się pojawią, są bolesne. Aktualizacja systemu operacyjnego to podstawa. Zrobiliśmy na wdrożeniu audyt i znaleźliśmy maszynę z 2014 roku z dziurawą biblioteką OpenSSL. Wystawioną na zewnątrz. To proszenie się o kłopoty.

Kolejny błąd to brak izolacji. Ludzie używają jednego, tego samego klucza prywatnego do wszystkich serwerów na produkcji, środowisk testowych i prywatnych VPS-ów. Jeśli klucz wycieknie, cała infrastruktura leży. Dobrą praktyką jest generowanie osobnych par kluczy dla różnych stref zaufania. Klucz do produkcji nigdy nie powinien znajdować się na tej samej maszynie, z której czytasz prywatne maile.

Brak automatycznego blokowania intruzów. Samo wyłączenie logowania na hasło to dużo, ale skanery dalej obciążają procesor swoimi próbami połączeń. Instalujesz narzędzie Fail2ban. Program czyta logi systemowe. Widzi, że ktoś z konkretnego IP próbował wejść pięć razy i oblał autoryzację. Fail2ban wrzuca ten adres IP do firewalla i blokuje go na poziomie warstwy sieciowej na 24 godziny. Ruch do sshd drastycznie spada. Maszyna oddycha z ulgą.

Wyzwania z utrzymaniem infrastruktury kluczy publicznych

Gdy firma rośnie, pliki authorized_keys zamieniają się w śmietnik. Przychodzi nowy deweloper, dodajesz jego klucz na piętnastu serwerach. Ktoś odchodzi z pracy, zapominasz usunąć jego wpis z jednej maszyny. Ma dostęp do firmowych danych z domowego komputera przez kolejne dwa lata. Znamy to z autopsji. Zarządzanie kluczami w modelu rozproszonym po prostu nie skaluje się przy zespole powyżej dwudziestu osób.

Rozwiązaniem jest użycie certyfikatów SSH. Zamiast kopiować klucze publiczne na każdy serwer, tworzysz wewnętrzny Urząd Certyfikacji (CA). Serwery są skonfigurowane tak, aby ufać podpisom tego urzędu. Kiedy pracownik przychodzi rano do biura, system wystawia mu certyfikat ważny tylko przez osiem godzin. Pracownik loguje się tym certyfikatem. Po godzinie 17:00 certyfikat wygasa. Nawet jeśli pracownik skopiuje go na pendrive i weźmie do domu, plik jest bezużyteczny. Odpada problem ręcznego czyszczenia serwerów po zwolnieniu członka zespołu.

Wdrożenie CA wymaga zmiany myślenia o dostępie. Przestajesz zarządzać plikami tekstowymi. Zaczynasz zarządzać procesem wydawania tożsamości. To trudniejsze na start, ale ułatwia sen w nocy osobom odpowiedzialnym za politykę bezpieczeństwa.

Czasami mam po prostu dość tłumaczenia tego samego na każdym audycie. Ludzie zostawiają domyślne ustawienia. Narzekają, że komendy są trudne do zapamiętania. Prawda jest taka, że opanowanie podstaw OpenSSH to kwesia jednego popołudnia z dokumentacją w ręku. Nie ma tutaj żadnej magii. Jest prosta matematyka, jasne reguły autoryzacji i pliki tekstowe. Jeśli nie potrafisz zabezpieczyć portu 22 w swojej infrastrukturze, nie powinieneś wystawiać do sieci żadnych usług. Zamknij luki. Skonfiguruj klucze. Odetnij roota. Zrób to teraz, zanim jutro rano zobaczysz zaszyfrowane dyski.

• FAQ – Najczęściej zadawane pytania
• 1. Czym różni się SSH od Telnetu?
  
  SSH szyfruje całą komunikację sieciową używając kryptografii, podczas gdy Telnet przesyła wszystkie dane, w tym hasła, czystym tekstem widocznym dla każdego w sieci.
• 2. Gdzie przechowywane są klucze SSH na komputerze?
  
  Domyślnie systemy Linux i macOS przechowują klucze w ukrytym katalogu ~/.ssh/ w folderze domowym użytkownika.
• 3. Czy muszę podawać hasło podczas generowania klucza?
  
  Nie musisz, ale powinieneś. Ustawienie hasła (passphrase) na plik klucza prywatnego chroni go w przypadku fizycznej kradzieży dysku.
• 4. Jak skopiować klucz na nowy serwer?
  
  Najprościej użyć polecenia ssh-copy-id nazwa_uzytkownika@adres_serwera, które automatycznie umieści klucz w odpowiednim pliku z poprawnymi uprawnieniami.
• 5. Co oznacza błąd „Permission denied (publickey)”?
  
  Serwer odrzucił połączenie, ponieważ nie rozpoznał twojego klucza publicznego, logowanie hasłem jest wyłączone lub katalog .ssh na serwerze ma złe uprawnienia.
• 6. Czy OpenSSH działa w systemie Windows?
  
  Tak. Klient i serwer OpenSSH są wbudowane w system Windows 10 i Windows 11. Można je włączyć w opcjach funkcji opcjonalnych systemu.

Bibliografia:

1. OpenSSH – https://www.openssh.com
2. Internet Engineering Task Force (IETF) – https://www.ietf.org
3. NASK – https://www.nask.pl
4. CERT Polska – https://cert.pl
5. Yubico – https://www.yubico.com