SSH (Secure Shell) to protokół szyfrowanego dostępu zdalnego – pozwala połączyć się z serwerem przez internet i pracować na nim tak, jakbyś siedział przy jego konsoli. Domyślnie działa na porcie 22.
Powstał w latach dziewięćdziesiątych jako zamiennik protokołów przesyłających hasła otwartym tekstem. Dziś jest podstawowym narzędziem administracji serwerami i tym, przez co łączy się z maszyną każdy, kto prowadzi własny VPS – choćby po to, żeby postawić na nim stronę albo uruchomić bota handlowego.
To hasło jest praktyczne. Jeśli masz serwer wystawiony do internetu, boty próbują się na niego zalogować już teraz – każda taka maszyna dostaje tysiące prób logowania dziennie, a wyszukiwarki urządzeń indeksują ponad dwadzieścia milionów usług SSH na świecie. Nikt Cię nie szuka. Skanuje się wszystko.
Jak to działa
Trzy warstwy, uruchamiane po kolei przy każdym połączeniu.
1. Uwierzytelnienie serwera. Serwer przedstawia się swoim kluczem hosta. Twój klient sprawdza, czy zna ten klucz – i tu wchodzi plik known_hosts, o którym zaraz.
2. Ustanowienie szyfrowania. Strony uzgadniają wspólny klucz sesji. Od tego momentu cały ruch jest zaszyfrowany.
3. Uwierzytelnienie użytkownika. Hasłem albo kluczem kryptograficznym. To jest miejsce, w którym zapada większość decyzji o bezpieczeństwie.
known_hosts – ostrzeżenie, które ludzie odklikują
Przy pierwszym połączeniu z serwerem SSH pyta, czy ufasz jego kluczowi. Odpowiadasz „tak”, klucz trafia do pliku known_hosts i przy kolejnych połączeniach jest sprawdzany automatycznie.
Jeśli kiedykolwiek zobaczysz komunikat o zmianie klucza hosta – zatrzymaj się.
To ostrzeżenie oznacza jedną z dwóch rzeczy: albo serwer został przeinstalowany, albo ktoś stoi między Tobą a serwerem i podszywa się pod niego. Pierwszy przypadek jest banalny, drugi oznacza, że Twoje hasło i wszystko, co wpiszesz, trafi do obcych rąk.
Odruchowe usuwanie wpisu z known_hosts, żeby „przestało wyskakiwać”, to wyłączanie jedynego mechanizmu, który przed tym chroni.
Klucze zamiast haseł
Najważniejsza pojedyncza zmiana, jaką możesz wprowadzić.
Uwierzytelnianie kluczem opiera się na parze: klucz prywatny zostaje u Ciebie, publiczny trafia na serwer. Serwer wysyła wyzwanie, Ty podpisujesz je kluczem prywatnym, serwer weryfikuje podpis publicznym. Klucz prywatny nigdy nie opuszcza Twojego komputera.
Przewaga nad hasłem jest strukturalna: hasła da się zgadywać, klucza o odpowiedniej długości nie.
Jaki typ klucza? Ed25519. Jest szybszy w generowaniu i weryfikacji, ma znacznie krótsze podpisy niż RSA i opiera się na krzywej pozbawionej znanych podatności na ataki czasowe. RSA nie jest zepsute, ale ed25519 jest lepsze pod każdym mierzalnym względem.
Zawsze ustawiaj hasło do klucza (passphrase). To jest punkt, który pomija większość ludzi, i to jest błąd. Klucz prywatny bez hasła to plik tekstowy, który każdy program mający dostęp do Twojego katalogu domowego może po prostu skopiować. Kampanie złośliwego oprogramowania rozprzestrzeniające się przez zainfekowane pakiety programistyczne zbierają klucze SSH jako jeden z priorytetowych celów – obok portfeli kryptowalutowych i tokenów dostępowych.
Żeby nie wpisywać hasła za każdym razem, używa się agenta kluczy, który trzyma odblokowany klucz w pamięci na czas sesji.
Utwardzanie serwera – konkretna lista
Osiem rzeczy. Wszystkie w pliku konfiguracyjnym sshd_config albo obok niego.
1. Wyłącz logowanie hasłem. Po skonfigurowaniu klucza. To jedna zmiana, która eliminuje całą kategorię ataków.
2. Zablokuj logowanie na konto root. Loguj się na zwykłego użytkownika i podnoś uprawnienia dopiero na miejscu.
3. Ogranicz liczbę prób i czas na zalogowanie. Krótszy czas na uwierzytelnienie i mniej dozwolonych prób w jednym połączeniu.
4. Zainstaluj narzędzie blokujące po nieudanych próbach, na przykład fail2ban. Automatycznie odcina adresy, z których sypią się nieudane logowania.
5. Ogranicz dostęp do konkretnych adresów IP, jeśli łączysz się ze stałej lokalizacji. To najskuteczniejsze zabezpieczenie z całej listy – reszta świata po prostu nie widzi Twojego portu.
6. Ogranicz listę użytkowników, którzy w ogóle mogą się logować.
7. Zmiana portu z 22 na inny ogranicza szum w logach, ale nie jest zabezpieczeniem. Skanery i tak znajdą usługę. Traktuj to jako higienę, nie jako ochronę.
8. Aktualizuj OpenSSH. O tym osobno niżej, bo rok 2026 dostarczył ku temu konkretnych powodów.
Przykładowy zestaw ustawień:
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
MaxAuthTries 3
LoginGraceTime 20
AllowUsers twojuzytkownik
Dwie rzeczy przed restartem usługi. Po pierwsze, sprawdź składnię poleceniem sshd -t. Po drugie – i to jest ważniejsze – miej otwartą drugą sesję albo dostęp przez konsolę dostawcy, zanim zrestartujesz demona. Błąd w konfiguracji przy zamkniętej jedynej sesji oznacza utratę dostępu do własnego serwera.
Tunele SSH
Funkcja, o której wielu użytkowników nie wie, a która bywa bardzo przydatna.
Przekierowanie lokalne przenosi port ze zdalnego serwera na Twój komputer. Praktyczne zastosowanie: baza danych na VPS-ie nie musi być w ogóle wystawiona do internetu – łączysz się z nią przez tunel, tak jakby działała lokalnie.
Przekierowanie zdalne działa odwrotnie – udostępnia port z Twojego komputera na serwerze.
Przekierowanie dynamiczne tworzy z SSH pełnoprawny serwer pośredniczący, przez który można kierować ruch aplikacji.
To jest lepszy wzorzec niż wystawianie kolejnych usług na świat. Im mniej portów otwartych na zewnątrz, tym mniejsza powierzchnia ataku – a tunel daje Ci dostęp bez ich otwierania.
Przekazywanie agenta – czego unikać
Jedna praktyka warta ostrzeżenia. Przekazywanie agenta kluczy (ForwardAgent) pozwala logować się z serwera na kolejny serwer przy użyciu klucza z Twojego komputera. Wygodne – i niebezpieczne, bo administrator maszyny pośredniej albo ktoś, kto ją przejął, może użyć Twojego agenta do zalogowania się wszędzie tam, gdzie masz dostęp.
Zamiast tego używa się przeskoku (ProxyJump), który zestawia połączenie przez maszynę pośrednią bez udostępniania jej Twoich kluczy.
Świeże podatności
Rok 2026 przypomniał, że sam protokół też bywa problemem.
W lipcu 2026 załatano serię ośmiu podatności w OpenSSH. Warto znać ich charakter, bo pokazuje różne wektory:
- CVE-2026-60000 i CVE-2026-60001 – osłabienie zabezpieczeń przed atakami siłowymi. Demon nie zawsze respektował minimalne opóźnienie między próbami uwierzytelnienia oraz limit prób, co pozwalało zgadywać hasła szybciej, niż zakładała konfiguracja.
- CVE-2026-59995 i CVE-2026-59996 – błędy po stronie klienta. Złośliwy serwer mógł przy pobieraniu plików skierować zapis w miejsce inne niż zamierzone.
- CVE-2026-60002 – najpoważniejsza z zestawu: błąd użycia zwolnionej pamięci w kliencie SSH, umożliwiający wykonanie kodu albo ujawnienie informacji przy ataku typu człowiek pośrodku.
Naprawiono to w OpenSSH 10.4. Dystrybucje zwykle przenoszą poprawki do starszych wersji pakietów.
Osobno pojawiła się CVE-2026-35414 – błędna obsługa listy uprawnionych w konfiguracji certyfikatów, w której przecinek w nazwie podmiotu prowadził do obejścia kontroli dostępu i możliwości uwierzytelnienia jako root. Dotyczy wersji przed 10.3.
Zwróć uwagę na wzorzec. Trzy z tych podatności dotyczą klienta, nie serwera. Łącząc się z cudzym serwerem SSH, też podejmujesz ryzyko – a to jest odwrotność intuicji, którą większość ludzi ma o tym protokole.
Dla porządku warto pamiętać też o głośnej luce regreSSHion (CVE-2024-6387) z lipca 2024, pozwalającej na zdalne wykonanie kodu z uprawnieniami roota. Dotyczyła wersji od 8.5p1 do 9.7p1 i została naprawiona w 9.8p1. Jeśli gdzieś nadal działa u Ciebie serwer z tamtego okresu, to jest priorytet numer jeden.
Jeśli trzymasz na serwerze coś wartościowego
Kilka zasad dla kogoś, kto uruchamia na VPS-ie bota handlowego albo cokolwiek dotykającego pieniędzy.
Klucze API z ograniczeniami. Klucz na serwerze nie powinien mieć uprawnień do wypłat. Powinien mieć przypisane adresy IP.
Żadnych kluczy prywatnych portfela na maszynie wystawionej do internetu. Serwer jest z definicji dostępny dla świata. Portfel nie powinien być.
Osobny klucz SSH do każdego serwera. Kompromitacja jednego nie otwiera wtedy wszystkich.
Aktualizacje automatyczne przynajmniej dla poprawek bezpieczeństwa. Okno między publikacją informacji o luce a jej wykorzystaniem liczy się dziś w dniach.
Monitoruj logi logowania. Jednorazowy rzut oka na to, kto i kiedy się logował, zajmuje minutę i bywa jedynym sygnałem, że coś jest nie tak.
Cztery mity
Mit 1: „Mam silne hasło, wystarczy.” Silne hasło można wykraść z Twojego komputera, przechwycić przy ataku pośrodku albo zgadnąć, jeśli okaże się mniej silne, niż sądziłeś. Klucz eliminuje wszystkie te scenariusze naraz.
Mit 2: „Zmieniłem port, boty mnie nie znajdą.” Znajdą. Skanowanie całego zakresu portów zajmuje minuty. Zmiana portu redukuje szum w logach, nie ryzyko.
Mit 3: „SSH jest szyfrowane, więc jestem bezpieczny.” Szyfrowanie chroni transmisję. Nie chroni przed słabym hasłem, skradzionym kluczem, podatnością w samym oprogramowaniu ani przed serwerem, który jest złośliwy.
Mit 4: „Ryzyko dotyczy tylko serwera.” Trzy z ośmiu podatności załatanych w lipcu 2026 dotyczyły klienta. Łączenie się z niezaufanym serwerem SSH niesie własne ryzyko.
Co zapamiętać
SSH to protokół szyfrowanego dostępu zdalnego, oparty na uwierzytelnieniu serwera kluczem hosta i uwierzytelnieniu użytkownika hasłem albo kluczem kryptograficznym.
Trzy rzeczy ponad resztą:
Klucz ed25519 z hasłem, logowanie hasłem wyłączone, root zablokowany. To trzy zmiany, które załatwiają większość realnego ryzyka.
Ostrzeżenie o zmianie klucza hosta to nie usterka. To jedyny mechanizm chroniący Cię przed atakiem pośrodku – nie usuwaj wpisu odruchowo.
Aktualizuj OpenSSH. Lipiec 2026 przyniósł osiem podatności naprawionych w wersji 10.4, w tym trzy dotyczące klienta, a nie serwera.
