SSH jak bunkier: bezpieczna konfiguracja, klucze, tunelowanie i dobre praktyki dla serwerów zdalnych

SSH jako brama do systemu – kontekst ryzyka i minimum bezpieczeństwa

SSH jako bunkier i główna furtka jednocześnie

SSH jest jednocześnie tarczą i najsłabszym ogniwem. Daje szyfrowany, uwierzytelniony dostęp do powłoki, plików i usług – czyli do wszystkiego, co na serwerze najważniejsze. Jeśli zostanie skonfigurowany byle jak, staje się idealnym punktem wejścia dla atakującego: nie trzeba już łamać aplikacji webowej czy bazy danych, wystarczy dostać powłokę przez SSH.

Na typowym serwerze w Internecie port 22 jest pierwszym celem botów i skanerów. Pojawiają się tysiące prób logowania do losowych kont, z listą popularnych haseł. Jeśli do tego dochodzi logowanie root, słabe hasło lub akceptowane uwierzytelnianie hasłem, to „bunkier” jest w praktyce chatką z dykty. Z perspektywy atakującego od tej jednej usługi często zależy powodzenie całej kampanii.

Z drugiej strony, dobrze twardo skonfigurowany SSH rzeczywiście przypomina bunkier: dostęp tylko z zaufanych adresów, tylko kluczem, po twardym bastionie, z limitem prób logowania i sensownymi algorytmami kryptograficznymi. W takim scenariuszu przejęcie systemu wymaga znacznie poważniejszych błędów w infrastrukturze, niż pojedyncze niedociągnięcie na serwerze.

„Działa” vs „jest bezpieczne” – trzy perspektywy

Z punktu widzenia administratora minimum to „da się zalogować, da się pracować”. Często kończy się na domyślnej konfiguracji dystrybucji, ewentualnie wyłączeniu logowania root. Z perspektywy audytora to nie wystarcza – liczy się zgodność z polityką bezpieczeństwa, minimalizacja powierzchni ataku i możliwość weryfikacji, kto co zrobił.

Napastnik patrzy na SSH zupełnie inaczej. Interesują go przede wszystkim:

• czy można próbować logowania hasłem,
• czy istnieje konto root lub inne „oczywiste” konta,
• czy limit prób logowania i czas blokady są łagodne,
• czy serwer akceptuje stare, słabe algorytmy, które da się lepiej atakować,
• czy dostęp jest możliwy z dowolnego miejsca w Internecie.

Jeśli konfiguracja sprowadza się do „domyślne + hasła”, bezpieczeństwo jest w praktyce kwestią szczęścia: czy bot trafił w Twoje hasło, czy nie. Jeśli natomiast zablokowano hasła, wymuszono klucze, ograniczono użytkowników i IP, audytor i administrator mogą realnie mówić o kontroli ryzyka.

Jeżeli jedynym testem SSH w organizacji jest „czy admin się zaloguje”, a nie ma audytu konfiguracji, to sygnał ostrzegawczy, że priorytetem jest wygoda, nie bezpieczeństwo.

Minimum bezpieczeństwa SSH, poniżej którego nie ma dyskusji

Istnieje zestaw elementów, które są absolutnym minimum dla serwera SSH wystawionego na świat:

• aktualna wersja OpenSSH (lub innego serwera), wolna od znanych podatności,
• wyłączone logowanie root (PermitRootLogin no),
• wyłączone uwierzytelnianie hasłem dla kont administracyjnych (PasswordAuthentication no, przynajmniej dla wybranych użytkowników/grup),
• uwierzytelnianie kluczem publicznym jako główna metoda logowania,
• domyślne konta (test, guest, user, admin) usunięte lub zablokowane,
• limity prób logowania i sesji (MaxAuthTries, MaxSessions, MaxStartups),
• logowanie zdarzeń SSH do sysloga oraz okresowy przegląd logów.

Bez tych punktów serwer SSH jest jak drzwi z solidnej stali, ale z zamkiem typu „klamka od środka” – wizualnie wygląda dobrze, operacyjnie jest słaby. Gdy choć kilka z powyższych warunków nie jest spełnionych, poziom ryzyka rośnie na tyle, że trzeba to traktować jako incydent projektowy, wymagający poprawy, a nie „kwestię stylu admina”.

SSH, RDP, VPN – kiedy SSH staje się jedyną barierą

W wielu środowiskach SSH jest jedyną bezpośrednio wystawioną usługą do zarządzania. Zdalny pulpit (RDP) jest tunelowany przez VPN, a do paneli www da się dostać bez logowania na serwer. W takim układzie SSH jest ostatnią linią obrony – jeśli padnie, atakujący ma pełną powłokę.

RDP jest wygodne, ale w praktyce bywa jeszcze częściej atakowane niż SSH. W modelu „VPN + RDP” ochroną przed Internetem jest głównie VPN. Jeśli jednak SSH jest wystawiony bezpośrednio, to konfiguracja SSH staje się równoważna konfiguracji VPN, tyle że dotyczy natywnego dostępu do systemu operacyjnego.

Jeśli serwer SSH jest wystawiony „solo” bez poprzedzającego VPN, a do tego przyjmuje hasła i logowanie root, to ocena ryzyka powinna być co najmniej tak surowa, jak dla wystawionego RDP bez NLA.

Sygnały ostrzegawcze, że SSH jest dziurawe

Istnieje kilka prostych testów, które od razu pokazują, że SSH jest skonfigurowane niebezpiecznie:

• możliwość logowania jako root z Internetu (PermitRootLogin yes lub without-password przy braku polityki kluczy),
• aktywne uwierzytelnianie hasłem dla wszystkich kont (PasswordAuthentication yes),
• otwarty port 22 z dowolnego IP bez ograniczeń firewallowych,
• brak logów o odrzucanych próbach logowania, choć serwer działa od dłuższego czasu (sugestia, że logi są ignorowane lub niewłączone),
• domyślna konfiguracja sshd_config bez żadnych własnych dyrektyw bezpieczeństwa.

Jeśli którykolwiek z powyższych punktów jest prawdziwy, nie ma mowy o „bunkrze” – to raczej tymczasowy barak. Jeżeli prawdziwych jest kilka z nich, priorytetem powinna być twarda konfiguracja SSH jeszcze przed kolejną zmianą aplikacji czy upgrade’em bazy danych.

Model zagrożeń dla SSH – kto atakuje i w jaki sposób

Automatyczne skanery, botnety i brutalne próby logowania

Każdy serwer SSH wystawiony na standardowym porcie 22 po kilku minutach od uruchomienia ma w logach pierwsze próby logowania. To zautomatyzowane skanery i botnety, które:

• skanują przestrzeń adresową i wykrywają otwarte porty,
• próbują logowania do standardowych kont (root, admin, user, test),
• używają słowników haseł (password, qwerty, 123456, nazwa_firmy itp.),
• wznowią ataki po zmianie adresu, jeśli wykryją ponownie znany fingerprint hosta.

W praktyce logi z /var/log/auth.log lub /var/log/secure bardzo szybko wypełniają się komunikatami typu „Failed password for invalid user admin from…”. Brak takich wpisów przy działającym SSH najczęściej oznacza, że logowanie jest źle skonfigurowane, a nie że serwer nie jest celem. Minimum to regularnie sprawdzać liczbę prób logowań nieudanych i dopasować limity oraz mechanizmy blokad (np. fail2ban).

Jeżeli w logach pojawiają się udane logowania dla niespodziewanych kont lub z niespodziewanych adresów, oznacza to, że atak automatyczny już wykracza poza fazę skanowania. W takiej sytuacji jedyną rozsądną reakcją jest natychmiastowa zmiana haseł, wyłączenie logowania hasłem oraz dokładny przegląd kluczy i uprawnień.

Ataki celowane: kradzież kluczy, MITM, złośliwy bastion

W środowiskach biznesowych lub administracjach publicznych częstszym celem jest nie tyle sam serwer, co stacja robocza administratora i jego klucze. Przykładowe scenariusze:

• zainfekowanie laptopa admina malware, które kradnie ~/.ssh/id_rsa i pliki konfiguracji,
• atak phishingowy wyłudzający passphrase do klucza (np. fałszywe okno terminala),
• man-in-the-middle (MITM) między klientem a serwerem w sieci niezaufanej, gdy fingerprint hosta nie jest weryfikowany,
• złośliwy lub źle zabezpieczony bastion SSH, który przechwytuje połączenia, agent forwarding i próby tunelowania.

Kradzież klucza bez passphrase jest równoznaczna z przejęciem konta, jeśli klucz jest dopuszczony do logowania na serwerach. Nawet klucz z passphrase można próbować łamać offline, zwłaszcza jeśli hasło jest krótkie. W takiej sytuacji ostatnią linią obrony staje się ograniczenie użycia klucza na serwerze (np. przez command=, from=, no-port-forwarding w authorized_keys).

Scenariusz MITM jest szczególnie groźny, gdy użytkownicy ignorują ostrzeżenia o zmianie fingerprintu hosta („REMOTE HOST IDENTIFICATION HAS CHANGED”). Jeśli standardem jest „tak, zawsze akceptuję”, atak polegający na podszyciu się pod serwer jest kwestią przejęcia jednej trasy sieciowej. Z punktu widzenia audytu każde takie ostrzeżenie powinno być badane, a nie omijane.

Błędy konfiguracyjne jako wektor ataku

Nawet bez zaawansowanej kryptografii, większość skutecznych włamań przez SSH opiera się na błędach konfiguracyjnych. Kluczowe przykłady:

• PermitRootLogin ustawione na yes lub bez przemyślanej polityki – root staje się pierwszym celem brute force,
• PasswordAuthentication yes bez żadnych ograniczeń i bez mechanizmów detekcji – atak może trwać miesiącami,
• akceptowane przestarzałe algorytmy (np. RSA 1024, DSA, CBC) – ułatwiają pewne klasy ataków kryptograficznych,
• AllowTcpForwarding yes i GatewayPorts yes bez kontroli – SSH staje się niekontrolowanym proxy do innych usług,
• brak MaxAuthTries – nieograniczona liczba prób logowania w jednej sesji.

Z perspektywy audytu konfiguracja sshd_config jest pierwszym dokumentem do przejrzenia. Jeśli zawiera sporo domyślnych ustawień, a wartości bezpieczeństwa nie są jawnie określone, można zakładać, że zabezpieczenia są dziełem przypadku dystrybucji, a nie decyzji projektowej. Minimalne twarde ustawienia powinny być wymuszone wprost, tak aby nie polegać na wersji i domyślnych politykach OpenSSH.

Różne środowiska, różne profile ryzyka

Nie każdy serwer SSH podlega tym samym wymaganiom. Inny jest profil ryzyka dla:

• małej firmy z jednym VPS-em w chmurze,
• shared hostingu, na którym wielu klientów ma konta shell,
• środowiska produkcyjnego w korporacji, z setkami serwerów i zespołem adminów,
• środowisk deweloperskich i testowych.

W małej firmie głównym zagrożeniem jest utrata dostępu (ransomware, przejęcie serwera i zmiana haseł), a także podsłuch danych. Priorytetem staje się więc backup kluczy, bezpieczne przechowywanie haseł do kont i twarda konfiguracja jednego czy dwóch serwerów. W dużej organizacji krytyczna jest z kolei skalowalność zarządzania kluczami, centralne logowanie, integracja z SIEM i polityka „least privilege”.

Jeśli środowisko jest produkcyjne i utrata jednej maszyny oznacza wymierne straty, poziom tolerowanego ryzyka dla SSH powinien być bardzo niski: brak haseł, brak logowania root, dostęp wyłącznie z sieci administracyjnej, twarde bastiony, obowiązkowe passphrase i rotacja kluczy. Dla deweloperki można dopuścić pewne kompromisy, ale tylko wtedy, gdy konsekwencje kompromitacji są ograniczone (np. środowisko całkowicie odseparowane od danych produkcyjnych).

Punkt kontrolny: akceptowalny poziom ryzyka

Każda decyzja o „poluzowaniu” SSH (np. dopuszczeniu haseł dla części użytkowników) powinna być konfrontowana z pytaniem: co się stanie, jeśli to konto zostanie przejęte? Jeśli odpowiedź brzmi „przejmą cały serwer, wszystkie dane i kopie zapasowe”, poziom ryzyka jest oczywiście nieakceptowalny.

Dobrą praktyką jest zdefiniowanie poziomów dostępu (np. tylko odczyt logów, administracja aplikacją, administracja systemem) oraz przypisanie do każdego z nich wymogów co do SSH (klucze, IP, bastiony, 2FA). Jeśli nie ma takiego formalnego lub choćby spisanego modelu, konfiguracja SSH często ewoluuje chaotycznie: kolejne wyjątki, kolejne „tymczasowe” hasła, kolejne otwarte porty. Im więcej wyjątków i nierównych zasad, tym łatwiej o błąd, który stanie się wejściem dla atakującego.

Fundamenty SSH – protokół, wersje, algorytmy, komponenty

SSH-1 vs SSH-2 – czego absolutnie nie używać

Protokół SSH-1 jest przestarzały i podatny na szereg ataków kryptograficznych. Współczesne serwery (OpenSSH od wielu lat) domyślnie obsługują tylko SSH-2 i tak powinno pozostać. Jeżeli znajdziesz w konfiguracji dyrektywy w rodzaju Protocol 2,1 albo opcje wymuszające SSH-1, to jasny sygnał, że konfiguracja pochodzi sprzed wielu lat i wymaga pilnej modernizacji.

Protokół SSH-2 wprowadza poprawione mechanizmy negocjacji kluczy, szyfrowania i uwierzytelniania. Większość współczesnych algorytmów, takich jak Ed25519 czy nowoczesne KEX, istnieje tylko w SSH-2. Dlatego Protocol 2 w sshd_config to minimum, a obecność SSH-1 powinna być traktowana jako krytyczna wada.

Składniki ekosystemu SSH: serwer, klient, klucze, agent

Bezpieczna konfiguracja wymaga zrozumienia, z czego SSH się składa. Podstawowe elementy to:

• serwer SSH (sshd) – demon nasłuchujący na porcie (domyślnie 22), implementujący politykę bezpieczeństwa z pliku sshd_config, listę uprawnionych kluczy oraz integrację z systemem kont,
• klient SSH (ssh) – program użytkownika, który inicjuje połączenie, negocjuje algorytmy, przedstawia klucz publiczny i obsługuje tunelowanie oraz przekierowania,
• zestaw kluczy – zwykle para prywatny/publiczny w ~/.ssh po stronie klienta oraz wpisy w ~/.ssh/authorized_keys (i ewentualnie ~/.ssh/known_hosts) po stronie serwera,
• agent SSH (ssh-agent / gpg-agent / keyring) – proces przechowujący odblokowane klucze w pamięci i udostępniający operacje kryptograficzne bez ujawniania materiału prywatnego.

Analizując incydenty, dobrze jest zawsze zadać trzy pytania: który komponent zawiódł, gdzie był brak kontroli oraz czy konfiguracja odpowiadała faktycznemu modelowi zagrożeń. Jeśli kompromitowany jest sam serwer (sshd), zwykle mamy do czynienia z błędną konfiguracją lub luką w oprogramowaniu. Jeżeli problemem jest klient lub stacja admina, najczęściej zawiniła ochrona kluczy, agent lub brak weryfikacji hostów. Im precyzyjniej oddzielisz te obszary, tym szybciej znajdziesz najsłabsze ogniwo.

Agent SSH to osobny punkt kontrolny. Ułatwia pracę (jedno odblokowanie klucza na wiele połączeń), ale równocześnie zwiększa powierzchnię ataku: złośliwy proces na stacji roboczej może próbować korzystać z agenta do uwierzytelniania się na serwerach, nawet bez poznania klucza prywatnego. Krytyczne jest więc ograniczenie czasu życia agenta, zakresu jego użycia (np. brak ForwardAgent wszędzie) oraz świadomość, gdzie agent jest faktycznie dostępny. Jeśli w audycie widzisz wszędzie ForwardAgent yes, a nikt nie potrafi wyjaśnić „po co”, to sygnał ostrzegawczy.

Osobną rolę pełni plik known_hosts. To nie jest „kosmetyczny” element, tylko mechanizm obrony przed MITM. Jeżeli użytkownicy rutynowo kasują ten plik, aby „pozbyć się ostrzeżeń”, cała kryptografia na warstwie transportowej traci sens. Minimum to ustandaryzować sposób zbierania i dystrybucji fingerprintów hostów (np. z repozytorium konfiguracyjnego) oraz zabronić ręcznego „czyszczenia” ostrzeżeń bez zgłoszenia do zespołu adminów. Jeśli zmiana klucza serwera nie ma procedury (kto, kiedy, jak aktualizuje known_hosts), przy pierwszej migracji łatwo o trwałe rozluźnienie dyscypliny.

Algorytmy KEX, szyfry i MAC – co faktycznie powinno być włączone

OpenSSH obsługuje dziesiątki algorytmów negocjacji klucza (KEX), szyfrowania i MAC. Z punktu widzenia bezpieczeństwa większość z nich jest zbędna, a część powinna być wyłączona. Dobór algorytmów to nie kosmetyka – to bezpośredni wpływ na odporność na ataki kryptograficzne i wydajność serwera.

Przy wyborze algorytmów kluczowe są trzy kryteria: aktualne rekomendacje kryptograficzne (np. z NIST, ENISA), stan implementacji w używanych klientach oraz profil ryzyka środowiska. Inny zestaw możesz zaakceptować w odizolowanym labie, a inny na bastionie z dostępem do produkcji.

Bezpieczne minimum dla KEX (negocjacja klucza) to dziś grupy oparte na krzywych eliptycznych i algorytmy z ECDH/Curve25519, np.:

• curve25519-sha256 / curve25519-sha256@libssh.org,
• ecdh-sha2-nistp256, ewentualnie inne krzywe z rodziny nistp, ale tylko tam, gdzie klienci nie obsługują Curve25519.

Algorytmy oparte na klasycznym DH z małymi grupami (diffie-hellman-group1-sha1, group14 bez rozszerzeń) stanowią sygnał ostrzegawczy. Jeśli musisz pozostawić DH (kompatybilność z bardzo starymi systemami), grupy powinny być duże, a SHA-1 wyłączony z negocjacji.

Dla szyfrów symetrycznych bezpieczne minimum to:

• chacha20-poly1305@openssh.com – bardzo dobra opcja dla systemów bez akceleracji AES,
• aes256-gcm@openssh.com / aes128-gcm@openssh.com – tryby AEAD (szyfrowanie + integralność),
• w dalszej kolejności aes256-ctr / aes128-ctr, jeśli musisz wspierać starszych klientów.

Szyfry CBC (aes256-cbc, 3des-cbc) oraz RC4/Blowfish powinny być traktowane jako niedopuszczalne poza bardzo kontrolowanymi wyjątkami. Ich obecność w konfiguracji to typowy punkt kontrolny przy audycie: jeśli widzisz cbc w Ciphers, konfiguracja była prawdopodobnie kopiowana „od zawsze” i nie była aktualizowana zgodnie z bieżącymi standardami.

MAC-y (kody integralności) w nowym podejściu powinny być zastępowane przez tryby AEAD (GCM, chacha20-poly1305), ale jeżeli MAC musi być jawnie skonfigurowany, priorytet mają algorytmy oparte na SHA-2, np. hmac-sha2-256, hmac-sha2-512. Obecność hmac-md5 i hmac-sha1 bez ograniczeń to kolejny sygnał ostrzegawczy.

Jeśli konfiguracja algorytmów nie jest sprecyzowana (polegasz na domyślnych ustawieniach OpenSSH), aktualizacja pakietu może nieoczekiwanie zmienić zestaw akceptowanych szyfrów. Jeśli środowisko jest krytyczne, wymuszaj explicite listę KexAlgorithms, Ciphers i MACs, a zgodność z klientami testuj przed wdrożeniem.

Typy kluczy: RSA, Ed25519, ECDSA – co realnie stosować

Na warstwie kluczy publicznych wybór sprowadza się dziś do trzech rodzin: RSA, Ed25519 i ECDSA. DSA jest przestarzałe i nie powinno być używane – jego obecność w konfiguracji (ssh-dss) to błąd.

Jako standard operacyjny warto przyjąć Ed25519:

• krótki klucz i podpisy (mniej danych do przenoszenia),
• wysoka odporność kryptograficzna przy niewielkim koszcie obliczeniowym,
• prosta, dobrze przeanalizowana krzywa.

RSA nadal bywa potrzebne ze względu na kompatybilność z niektórymi starszymi systemami i bibliotekami. Jeżeli pozostawiasz RSA, minimum to klucze 3072-bitowe, a lepiej 4096-bitowe, z wyłączonymi kluczami 1024-bitowymi i krótszymi. W konfiguracji serwera upewnij się, że lista PubkeyAcceptedAlgorithms nie otwiera furtki dla ssh-rsa opartego na SHA-1, jeśli nie jest to absolutnie konieczne.

ECDSA (klucze ecdsa-sha2-nistp256) można traktować jako uzupełnienie, gdy środowisko klienckie nie obsługuje Ed25519, ale ma wsparcie dla ECDSA z biblioteki systemowej. Jeżeli nie masz w organizacji wymagań regulatora, który narzuca konkretne krzywe, Ed25519 + RSA 4096-bit jako fallback pokrywa większość scenariuszy.

Jeżeli w audycie widzisz, że większość kluczy to stare RSA 1024-bit generowane „dawno temu”, a nikt nie zna daty ich powstania ani nie ma procedury rotacji, trzeba zakładać, że polityka kluczy po prostu nie istnieje. W takiej sytuacji migracja do Ed25519 powinna być zaplanowana jako osobny projekt z jasno określonymi etapami i terminami.

Jeśli środowisko jest konserwatywne, nie rezygnuj z RSA od razu – najpierw wprowadź Ed25519 równolegle jako wymóg dla nowych dostępów, a RSA pozostaw jako kompatybilność wsteczną, z twardym terminem wyłączenia.

Komunikaty banera i LogLevel jako narzędzia kontroli

SSH pozwala na ustawienie komunikatów powitalnych (baner) oraz poziomu logowania. Oba te elementy są często traktowane po macoszemu, tymczasem pełnią realną funkcję kontrolną i prawną.

Baner (Banner /etc/issue.net) nie powinien zdradzać szczegółów technicznych. Informacje w rodzaju „Debian 9, OpenSSH_7.4, kernel 4.9” pomagają atakującemu dopasować exploit. Bezpieczniejszym podejściem jest baner zawierający:

• ostrzeżenie o monitorowaniu i braku prywatności na systemie,
• odniesienie do regulaminu/zasad korzystania,
• zakaz nieautoryzowanego dostępu bez wskazywania technologii.

LogLevel w sshd_config jest punktem kontrolnym dla audytora. Ustawienie QUIET poza specyficznymi zastosowaniami (np. wbudowane urządzenia z osobnym logowaniem) jest sygnałem ostrzegawczym. Minimum w środowisku produkcyjnym to INFO, a przy analizie incydentów czasowo VERBOSE. Poziom DEBUG na stałe zwykle jest nieuzasadniony – generuje zbyt dużo danych i może potencjalnie ujawniać szczegóły konfiguracji.

Jeżeli logi SSH nie zawierają informacji o nieudanych próbach logowania, adresach IP i użytych metodach uwierzytelniania, system monitoringu nie ma na czym pracować. W takiej sytuacji choćby najlepsza konfiguracja kryptograficzna traci sens, bo nikt nie widzi prób włamania.

Jeśli baner zawiera dane o wersji systemu lub konkretnej dystrybucji, to prosty punkt do poprawy. Jeśli logi SSH nie trafiają do centralnego systemu logowania lub są czyszczone bez retencji, trzeba założyć, że wykrywalność incydentów jest na minimalnym poziomie.

Klucze SSH krok po kroku – generowanie, przechowywanie, polityka

Generowanie kluczy: parametry, które ustalasz raz, a potem odczuwasz latami

Dla większości użytkowników wygenerowanie klucza to jedno polecenie, zwykle skopiowane z pierwszego wyniku wyszukiwarki. W środowisku, w którym klucze dają dostęp do produkcji, takie podejście jest nieakceptowalne. Zanim dopuszczony zostanie jakikolwiek schemat generowania, trzeba jasno ustalić zestaw parametrów.

Podstawowe wzorce dla OpenSSH:

• klucze użytkowników: ssh-keygen -t ed25519 -C "imię.nazwisko@firma" -f ~/.ssh/id_ed25519,
• fallback dla starszych systemów: ssh-keygen -t rsa -b 4096 -o -a 100 -C "imię.nazwisko@firma" -f ~/.ssh/id_rsa.

Opcja -o włącza nowszy format pliku prywatnego (OpenSSH), a -a zwiększa koszt obliczeniowy KDF przy zabezpieczaniu klucza passphrase. W praktyce podniesienie -a (np. do 100–200) znacząco wydłuża czas łamania hasła z użyciem GPU, jednocześnie pozostając akceptowalne dla użytkownika przy odblokowaniu klucza.

Passphrase do klucza nie powinna być prostym hasłem z polityki „8 znaków, litera, cyfra, znak specjalny”. To raczej krótka fraza zdaniowa lub losowa sekwencja przechowywana w menedżerze haseł. Kryteria minimum:

• unikatowa (nigdzie indziej nieużywana),
• odporna na zgadywanie ze słownika,
• niezależna od haseł systemowych użytkownika.

Jeśli użytkownicy tworzą klucze lokalnie bez wytycznych, powstaje mieszanka RSA 2048, RSA 1024, Ed25519 i kluczy bez passphrase. Z punktu widzenia audytu taka sytuacja oznacza brak centralnej polityki kluczy – i konieczność uporządkowania stanu przed kolejnym przeglądem bezpieczeństwa.

Struktura katalogu ~/.ssh i uprawnienia

Katalog ~/.ssh bywa traktowany jak „dowolny folder użytkownika”. Tymczasem jest to przestrzeń, która bezpośrednio decyduje o integralności mechanizmu uwierzytelniania. Minimum kontrolne to:

• uprawnienia 0700 dla katalogu ~/.ssh,
• 0600 dla kluczy prywatnych (id_ed25519, id_rsa itd.),
• 0644 lub ciaśniejsze dla authorized_keys i known_hosts.

OpenSSH domyślnie odmawia użycia kluczy przy zbyt szerokich uprawnieniach, ale nie na wszystkich platformach egzekwowanie jest jednakowo restrykcyjne. Dlatego podczas audytu warto porównać realne uprawnienia plików z polityką wzorcową, zamiast zakładać, że „sshd się tym zajmie”.

Struktura katalogu powinna być przewidywalna: pliki kluczy prywatnych, klucze publiczne, authorized_keys, ewentualnie podkatalogi na klucze specyficzne dla środowisk (np. ~/.ssh/prod/) z odpowiednimi skryptami uruchamiającymi agenta. Każdy „twórczy” pomysł użytkownika (wiele kopii klucza w różnych katalogach, pliki bez rozszerzeń .pub) utrudnia zarządzanie i audyt.

Jeśli użytkownik ma wiele kluczy w przypadkowych lokalizacjach, a jedyną kopią wzorcową jest jego lokalny laptop, utrata lub kompromitacja stacji roboczej oznacza chaos. Jeżeli znalezienie aktualnego klucza użytkownika wymaga pytania go mailowo „co pan ma w ~/.ssh?”, proces zarządzania kluczami nie istnieje w praktyce.

authorized_keys – finezyjne ograniczanie uprawnień klucza

Plik ~/.ssh/authorized_keys to nie tylko lista kluczy. To również miejsce, gdzie można przypisać ograniczenia do konkretnego klucza, zamykając wiele wektorów ataku bez ingerowania w główną konfigurację serwera.

Do najważniejszych opcji należą:

• command="...." – wymuszenie konkretnej komendy po zalogowaniu (np. dla konta backupowego),
• from="1.2.3.4/32,10.0.0.0/24" – ograniczenie adresów IP, z których klucz może być użyty,
• no-port-forwarding, no-X11-forwarding, no-agent-forwarding – wyłączenie wybranych funkcji tunelowania i przekazywania,
• permitopen="host:port" – precyzyjne ograniczenie, dokąd można tunelować.

Przykład wpisu dla konta, które ma służyć wyłącznie do wykonywania kopii zapasowej z konkretnego serwera administracyjnego:

from="10.0.10.5",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,
command="/usr/local/sbin/run_backup.sh" 
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB... komentarz

W takim scenariuszu kompromitacja klucza nie pozwoli napastnikowi na interaktywne logowanie ani użycie konta do pivotu w sieci. Klucz przyda się wyłącznie do uruchomienia zaprogramowanego procesu, z konkretnego adresu. To często wystarczy, aby zdusić skutki wycieku.

Jeżeli w audycie widzisz klucze używane przez aplikacje (backup, CI/CD, monitoring) bez żadnych ograniczeń w authorized_keys, przyjmij założenie, że potencjalne skutki ich przejęcia są równe skutkom przejęcia zwykłego konta interaktywnego. W takim przypadku trzeba albo dociążyć te wpisy odpowiednimi opcjami, albo przenieść zadania na dedykowane konta z minimalnymi uprawnieniami.

Polityka rotacji i wygaszania kluczy

Klucze SSH często traktowane są jak „na zawsze”. Admin wygenerował klucz pięć lat temu, używa go do wszystkiego – od dewelopki po produkcję – i nie widzi powodu, aby go zmieniać. Zgodnie z najlepszymi praktykami taka sytuacja jest niedopuszczalna, szczególnie tam, gdzie wymagane są ścieżki audytowe i kontrola dostępu w czasie.

Polityka rotacji powinna jasno określać:

• maksymalny czas życia klucza (np. 12–24 miesiące w środowisku o umiarkowanym ryzyku, krócej w krytycznym),
• wymóg wymiany klucza po incydencie dotyczącym stacji roboczej użytkownika (podejrzenie malware, utrata laptopa),
• wymóg natychmiastowego unieważnienia klucza po zmianie roli użytkownika (np. przejście z działu operacji do deweloperów),
• procedurę wygaszania kluczy nieużywanych (np. brak logowania danym kluczem przez 90 dni oznacza jego deaktywację),
• technikę przeprowadzania rotacji bez okien serwisowych (okres współistnienia starego i nowego klucza, kontrola logów, potem usunięcie starego).

Dojrzała organizacja nie czeka, aż „ktoś sobie przypomni o kluczach”. Rotacja jest procesem regularnym, z harmonogramem i odpowiedzialnym właścicielem. Jeżeli w logach da się znaleźć ten sam klucz używany od wielu lat na produkcji, a zmiany personalne nie skutkują automatycznym wygaszaniem dostępu, to wyraźny sygnał ostrzegawczy z punktu widzenia zgodności i ryzyka operacyjnego.

Dobrą praktyką jest rozdzielenie kluczy per kontekst: osobny klucz do środowisk produkcyjnych, osobny do testowych, a w większych firmach także osobne klucze na projekty. Upraszcza to rotację (można wymienić wyłącznie „klucze prod”), a przy incydencie zawęża zakres działań. Jeżeli jeden kompromitowany klucz otwiera wszystkie środowiska i systemy, każdy incydent staje się jednocześnie ćwiczeniem z odzyskiwania całej infrastruktury.

Proces rotacji musi być oparty o dane, nie o deklaracje. Minimum to okresowe porównanie listy kluczy z logami uwierzytelniania: które nie były używane od dawna, które logują się wyłącznie z podejrzanych zakresów IP, które należą do osób już nieobecnych w organizacji. Jeżeli takie zestawienia nie powstają, zarządzanie kluczami jest wyłącznie teoretyczne – formalna polityka istnieje, ale nie ma realnej kontroli.

Jeżeli konfiguracja kryptograficzna, polityka kluczy, ustawienia sshd_config i zasady dostępu do kont tworzą spójny zestaw, SSH rzeczywiście staje się „bunkrem” – nawet przy intensywnym ruchu i zewnętrznej ekspozycji. Jeśli natomiast choćby jeden z tych filarów jest zaniedbany (brak logów, brak rotacji kluczy, powszechny dostęp do roota), cała konstrukcja zaczyna przypominać bunkier z otwartymi drzwiami: solidne ściany nie zrekompensują braku dyscypliny operacyjnej.

sshd_config jako bunkier – twarda konfiguracja serwera SSH

Konfiguracja sshd decyduje, czy serwer przyjmuje się jak twierdzę, czy jak serwis typu „dla każdego coś miłego”. Przy audycie konfiguracyjnym punktem wyjścia jest zawsze plik /etc/ssh/sshd_config (oraz ewentualne pliki włączane dyrektywą Include).

Porządek w plikach i dziedziczenie konfiguracji

Na wielu dystrybucjach sshd_config jest modyfikowany przez kolejne aktualizacje pakietów, a administratorzy dopisują własne bloki poniżej. Po kilku latach powstaje konfiguracja nieprzewidywalna, z duplikatami dyrektyw i przypadkowymi nadpisaniami ustawień.

Podstawowy porządek to:

• minimalizowanie liczby plików Include – jeden katalog na lokalne modyfikacje (/etc/ssh/sshd_config.d/) zamiast losowo rozproszonych plików,
• brak duplikatów dyrektyw w jednym zakresie (Host *) – ostatnia wartość wygrywa, ale utrudnia to audyt,
• komentarze z datą i autorem przy zmianach odstających od standardu dystrybucji,
• utrzymywanie osobno szablonu „wzorcowego” (np. w repozytorium), względem którego porównuje się produkcję.

Jeżeli w jednym pliku występują po trzy różne wartości PermitRootLogin lub PasswordAuthentication, a jedyną metodą ustalenia stanu jest test „na żywo”, to sygnał ostrzegawczy: konfiguracja nie jest pod kontrolą, tylko dryfuje.

Wymuszenie silnej kryptografii

Podstawą jest jawne zadeklarowanie akceptowanych algorytmów, zamiast polegania na domyślnych ustawieniach. Dwa kluczowe bloki to:

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
HostKeyAlgorithms ssh-ed25519,ssh-rsa
PubkeyAcceptedKeyTypes ssh-ed25519,ssh-rsa

W nowych instalacjach RSA bywa już zbędne, ale w środowiskach mieszanych często trzeba utrzymać kompatybilność. Kryteria minimalne:

• preferencja Ed25519 (ssh-ed25519) jako głównego algorytmu klucza serwera i użytkowników,
• RSA tylko w wariancie co najmniej 3072/4096 bitów (sprawdzać w /etc/ssh/ssh_host_rsa_key.pub),
• wyłączone algorytmy historyczne: DSA (ssh-dss), ECDSA na słabych krzywych, MD5 w MAC-ach.

Przy audycie konfiguracji minimum to sprawdzenie, czy w ogóle występują jawne listy KexAlgorithms, HostKeyAlgorithms, Ciphers, MACs. Jeżeli ich nie ma, cała polityka kryptograficzna zależy od wersji OpenSSH zainstalowanej na danym serwerze, co utrudnia spójność w infrastrukturze.

Wyłączenie uwierzytelniania hasłem

Główna dźwignia zmniejszająca powierzchnię ataku to przejście wyłącznie na klucze publiczne. W konfiguracji:

AuthenticationMethods publickey
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

lub – w środowiskach przejściowych –:

AuthenticationMethods publickey,password
PasswordAuthentication yes

ale wtedy wymagany jest konkretny plan czasowego wygaszenia haseł. Punkty kontrolne:

• czy w logach występuje masowy brute force na hasła (Failed password for invalid user) – jeśli tak, to PasswordAuthentication nie jest wyłączone,
• czy użytkownicy mają jeszcze realną potrzebę logowania hasłem (np. automaty dla których nigdy nie przygotowano kluczy),
• czy polityka haseł systemowych jest wystarczająco mocna, jeżeli hasła nadal są używane jako dodatkowy faktor.

Jeżeli serwer dostępny z Internetu akceptuje logowanie hasłem, a liczba błędnych prób w logach idzie w tysiące dziennie, to sygnał ostrzegawczy wskazujący na pilną potrzebę migracji do modelu „klucz + ew. drugi faktor”.

Ograniczenie słuchania interfejsów i portów

Domyślnie sshd nasłuchuje na wszystkich interfejsach. W praktyce często wystarcza ekspozycja tylko na sieć administracyjną lub lokalny adres:

Port 22
ListenAddress 10.0.10.1
ListenAddress 127.0.0.1

Jeżeli serwer ma wiele interfejsów (np. DMZ, sieć wewnętrzna, zarządzająca), trzeba jasno wskazać, gdzie SSH jest dopuszczone. Nadmiarowe nasłuchiwanie bywa niezauważone, a to otwarta furtka.

Port niestandardowy (Port 2222 zamiast 22) nie jest mechanizmem bezpieczeństwa sensu stricto, ale redukuje hałas skanów masowych. Przy audycie ocenić trzeba nie „czy port jest dziwny”, ale:

• czy firewall wymusza ograniczenie dostępu do portu SSH do wybranych podsieci/źródeł,
• czy zmiana portu nie jest jedyną linią „obrony”, maskując brak twardej konfiguracji.

Jeżeli serwer słucha na wszystkich interfejsach, w tym publicznym, a firewall dopuszcza ruch z całego Internetu, ciężar ochrony spada wyłącznie na sshd. To sytuacja akceptowalna tylko wtedy, gdy reszta polityki (klucze, 2FA, ograniczenia kont) jest bez zarzutu.

Ograniczenia funkcji protokołu

SSH to nie tylko powłoka i kopiowanie plików. Włączone domyślnie funkcje tunelowania potrafią niezauważenie stać się wektorem obejścia segmentacji sieci.

AllowTcpForwarding no
GatewayPorts no
PermitTunnel no
X11Forwarding no

W większości środowisk nic nie uzasadnia globalnego AllowTcpForwarding yes. Wyjątki (np. bastiony do tunelowania na bazy danych) powinny mieć osobne serwery lub precyzyjne reguły w Match i authorized_keys (permitopen). Punkty kontrolne:

• czy są serwery, które pełnią funkcję nieformalnych „VPN przez SSH”,
• czy użytkownicy potrafią bez nadzoru tworzyć tunele do dowolnych hostów,
• czy architektura sieci uwzględnia ten fakt (logowanie, monitoring, segmentacja).

Jeżeli tunelowanie jest szeroko włączone, a właściciel systemu nie potrafi wskazać, gdzie trafia ruch przechodzący przez bastion, to typowy sygnał ostrzegawczy – kontrola nad przepływem danych jest częściowo iluzoryczna.

Użycie sekcji Match do segmentacji polityk

Dyrektywa Match pozwala na różne polityki dla różnych użytkowników, grup czy źródeł. Przykładowo:

Match Group admins
    AllowTcpForwarding yes
    X11Forwarding no

Match User deploy
    AllowTcpForwarding no
    ForceCommand /usr/local/sbin/deploy.sh

Match Address 192.0.2.0/24
    PasswordAuthentication no

To narzędzie często niedoceniane. Pozwala jednak budować bunkier wielowarstwowy: inne zasady dla kont serwisowych, inne dla administratorów, inne dla zaufanych sieci wewnętrznych. Kryteria minimum:

• brak globalnych „luźnych” ustawień, które potem są w jedynym miejscu ostrzej przykręcane (Match all),
• jasne, udokumentowane reguły – bez nieczytelnych, zagnieżdżonych Match o niejasnym działaniu,
• testy po każdej zmianie w Match (różne scenariusze logowania, aby uniknąć blokady dostępu).

Jeżeli konfiguracja używa Match w sposób ad hoc, np. dopisywane lata temu wyjątki „na szybko”, a dziś nikt nie wie, kogo dotyczą – trzeba to traktować jako zadłużenie techniczne i stopniowo porządkować.

Logowanie i integracja z monitoringiem

Bez logów nie ma bunkra, jest zgadywanie. Konfiguracja sshd musi być spójna z polityką logowania systemu:

LogLevel VERBOSE

Poziom VERBOSE pozwala m.in. na logowanie odcisku palca klucza przy uwierzytelnieniu, co jest kluczowe przy śledzeniu, którego klucza użyto. Warto powiązać to z centralnym systemem logowania (syslog, journald + forward, SIEM).

Punkty kontrolne:

• czy logi SSH są zbierane centralnie z produkcji, a nie tylko pozostawione lokalnie na serwerze,
• czy istnieją reguły korelacji – np. powiadomienia przy wielu nieudanych próbach logowania, przy logowaniu z nowych krajów, przy pierwszym użyciu danego klucza po długiej przerwie,
• czy LogLevel nie został przypadkowo obniżony do ERROR z powodu problemów wydajnościowych lub braku dysku.

Jeżeli incydent „nietypowe logowanie” musi być analizowany na podstawie szczątkowych danych, a nie ma możliwości odtworzenia, jakim kluczem i skąd zalogowano się na serwer, to organizacja operuje de facto bez oczu.

Kontrola dostępu – konta, grupy, sudo, rola root

Nawet najlepsze klucze i konfiguracja sshd nie pomogą, jeśli model kont i uprawnień jest przypadkowy. SSH widzi konta systemowe, dlatego wewnętrzny porządek na poziomie użytkowników i grup bezpośrednio przekłada się na bezpieczeństwo zdalne.

Indywidualne konta vs. konta współdzielone

Standardem w środowiskach regulowanych jest całkowite unikanie kont współdzielonych (np. wspólne „admin”, „oracle”, „deploy”). Zamiast tego:

• każdy administrator ma osobiste konto systemowe powiązane z tożsamością (AD/LDAP lub /etc/passwd),
• podwyższanie uprawnień odbywa się przez sudo z logowaniem komend,
• ewentualne konto „techniczne” (np. deploy) ma wyłączone logowanie z konsoli oraz ścisłe ograniczenia w authorized_keys / ForceCommand.

Jeżeli w audycie występuje konto root lub admin, do którego „wszyscy admini znają hasło”, to nie jest to punkt do dyskusji, tylko krytyczny sygnał ostrzegawczy – brak jakiejkolwiek rozliczalności.

Grupowanie uprawnień i segmentacja ról

Najczęściej spotykany błąd to jedna „grupa uprzywilejowana” (np. wheel, sudo) dla wszystkich, niezależnie od roli. Minimum to wyodrębnienie co najmniej trzech poziomów:

• administracja systemowa (np. sysadmin) – pełne sudo z dodatkową kontrolą,
• administracja aplikacyjna (np. appadmin) – dostęp tylko do konkretnych usług, plików i poleceń,
• użytkownicy operacyjni (np. ops) – czytanie logów, restart wybranych usług, bez dostępu do konfiguracji systemu.

Następny krok to spójność tych grup z konfiguracją sshd (dyrektywy AllowGroups, DenyGroups) oraz sudoers. Jeżeli ktoś jest w grupie „admins”, ale sshd i sudo o tym nie wiedzą, grupa ma znaczenie wyłącznie teoretyczne.

Polityka dostępu przez AllowUsers / AllowGroups

Przy dużej liczbie kont proste założenie „każdy lokalny użytkownik może logować się przez SSH” jest nie do obrony. W sshd_config powinien się pojawić jawny filtr, np.:

AllowGroups ssh-users ssh-admins
DenyUsers test guest
DenyGroups nologin

W mniejszych środowiskach wystarczy lista użytkowników:

AllowUsers jan.kowalski anna.nowak deploy

Punkty kontrolne:

• czy wszystkie konta mają przypisaną konkretną rolę i wiadomo, dlaczego wolno im logować się po SSH,
• czy istnieje grupa „techniczna” typu sshd-deny / nologin, do której trafiają konta serwisowe bez zdalnego logowania,
• czy nowe konta domyślnie nie mają prawa logowania, dopóki ktoś nie doda ich do odpowiedniej grupy.

Jeżeli administrator dodaje konta, które z automatu mogą logować się po SSH, a żadna grupa nie pełni funkcji „gatekeepera”, z czasem powstanie zbiór nieużywanych, ale nadal aktywnych dostępów.

Rola root i obowiązkowe sudo

Dostęp bezpośredni do roota zdalnie jest w dojrzałych środowiskach traktowany jako wyjątek, nie standard. Podstawowe ustawienie to:

PermitRootLogin no

W skrajnie wymagających scenariuszach dopuszcza się czasową zmianę na:

PermitRootLogin prohibit-password

aby wpuścić roota wyłącznie z klucza, ale wtedy konieczna jest szczególnie rygorystyczna kontrola nad tym kluczem (osobny, rotowany, z restrykcjami IP i czasu).

Za to sudo powinno być włączone i skonfigurowane tak, aby:

• logować wszystkie komendy (syslog, journald, najlepiej do systemu centralnego),
• wymagać ponownego podania hasła użytkownika po określonym czasie bezczynności (timestamp_timeout),
• umożliwiać precyzyjne ograniczenie komend (lista dozwolonych poleceń zamiast ogólnego ALL=(ALL) ALL dla wszystkich),
• wspierać rozdzielenie ról – inni ludzie w grupie „appadmin”, inni w „sysadmin”, z różnymi przywilejami w sudoers.

W konfiguracji /etc/sudoers lepiej unikać globalnych reguł typu „wszyscy w grupie sudo mogą wszystko bez hasła”. Bezpieczniejszy wzorzec to: ograniczona liczba pełnych administratorów z wymuszonym hasłem oraz odrębne wpisy dla zadań rutynowych, np. restart wybranych usług dla zespołu operacyjnego. Dobrym punktem kontrolnym jest przegląd logów sudo – jeżeli widoczne są głównie polecenia typu sudo su - i długie sesje roota bez kontekstu, mechanizm rozliczalności jest w praktyce wyłączony.

Jeżeli w trakcie przeglądu konfiguracji nie da się odpowiedzieć, które konkretnie polecenia może wykonać dany operator bez podwyższania uprawnień, a które przez sudo, to system uprawnień jest zbyt rozmyty. W takim przypadku incydent z błędną komendą „na szybko” jest tylko kwestią czasu, a ustalenie odpowiedzialności – prawie niemożliwe.

Audyt kont, kluczy i uprawnień – cykl życia dostępu

Model bezpieczeństwa SSH wymaga regularnego przeglądu, a nie jednorazowej konfiguracji. Minimum to okresowy (np. kwartalny) audyt:

• kont systemowych – kto nadal pracuje, które konta są nieużywane i mogą zostać zablokowane,
• kluczy w authorized_keys – czy każdy klucz ma właściciela, opis i powód istnienia,
• grup i sudoers – czy przywileje nadal odpowiadają faktycznej roli.

Przydatna jest prosta procedura „offboardingu”: wyjście pracownika lub kontraktora oznacza w przewidywalnym czasie usunięcie z grup, unieważnienie kluczy, zablokowanie konta i, w razie potrzeby, rotację haseł/kanałów używanych wspólnie (np. konta aplikacyjne). Jeżeli ta ścieżka nie istnieje, dawni administratorzy utrzymują praktycznie nieograniczony, niewidoczny dostęp.

Sygnałem ostrzegawczym są katalogi ~/.ssh/authorized_keys z wieloletnim „osadem” kluczy, których nikt nie potrafi przypisać do konkretnej osoby lub roli. W takim przypadku trzeba założyć, że część z nich jest już poza kontrolą organizacji – klucze mogły trafić do prywatnych repozytoriów, na stare laptopy, do dawnych wykonawców. Wprowadzenie jawnego rejestru kluczy (choćby w arkuszu, w mniejszych środowiskach) oraz zasady wygasania/odnowienia po określonym czasie zamyka ten problem w przewidywalnych ramach.

Spójność: od sieci po logi

Bezpieczeństwo SSH nie zależy wyłącznie od sshd_config czy jakości kluczy. Liczy się cała linia obrony: filtracja na poziomie sieci (firewalle, listy ACL), kontrola, kto może w ogóle dotrzeć do portu 22, spójne grupy i role systemowe, twarde zasady sudo oraz sensownie dobrany poziom logowania z wysyłką do systemu centralnego. Dopiero taki komplet tworzy bunkier, w którym incydent nie jest katastrofą, tylko scenariuszem przewidzianym i możliwym do prześledzenia.

Jeżeli z audytu wynika, że dostęp po SSH ma dowolny użytkownik, z dowolnej sieci, z dowolnego urządzenia, a logi są tylko lokalne, to konfiguracja jest de facto zbiorem życzeń. Bunkier zaczyna się tam, gdzie każdemu elementowi łańcucha bezpieczeństwa można zadać proste pytanie „kto, co, skąd i na jakich zasadach” – i uzyskać konkretną, udokumentowaną odpowiedź.

Tunelowanie SSH – bezpieczne kanały w nieprzyjaznej sieci

SSH to nie tylko powłoka. To także fabryka szyfrowanych tuneli, którymi można transportować inne protokoły. Z punktu widzenia bezpieczeństwa to zarówno ogromne narzędzie, jak i potencjalna dziura w zaporze, jeżeli nikt nie kontroluje, co jest tunelowane.

LocalForward – dostęp do usług wewnętrznych z zewnątrz

Najczęściej wykorzystywany wariant tunelu to przekierowanie lokalne (local port forwarding). Klasyczny przykład: dostęp do panelu administracyjnego bazy danych, który z założenia nie wychodzi poza sieć lokalną serwera:

ssh -L 5433:127.0.0.1:5432 admin@serwer-bazy

Taki tunel tworzy lokalny port 5433 na stacji administratora, który jest szyfrowany i przekazywany do portu 5432 (np. PostgreSQL) na serwerze. Z zewnątrz port bazy nie jest widoczny, a ruch tranzytowy przechodzi wyłącznie przez połączenie SSH.

Punkty kontrolne przy LocalForward:

• czy tunelowane są wyłącznie usługi, które są realnie potrzebne, czy jest to „stały zwyczaj wygody” bez refleksji,
• czy porty lokalne nie są wystawiane na wszystkie interfejsy (binding do 0.0.0.0 zamiast 127.0.0.1),
• czy usługa po drugiej stronie ma własne mechanizmy autoryzacji, czy tunel faktycznie pełni rolę jedynej „bramy”.

Jeżeli w konfiguracji i nawykach administratorów często pojawia się -L 0.0.0.0:XXXX:..., to sygnał ostrzegawczy – taki tunel z lokalnego portu robi mini‑serwer proxy dostępny dla innych urządzeń w sieci użytkownika.

RemoteForward – gdy serwer dzwoni do klienta

Przekierowanie zdalne (RemoteForward) działa odwrotnie: to serwer otwiera port i przekazuje ruch do klienta. Praktyczny przykład: tymczasowy dostęp operatorski do stacji roboczej znajdującej się za NAT-em, bez ingerencji w reguły firewalla:

ssh -R 9000:127.0.0.1:22 ops@bastion

Na serwerze bastion powstaje port 9000; połączenie do niego trafia przez tunel na port 22 lokalnej maszyny użytkownika. Rozwiązanie wygodne, ale z perspektywy bezpieczeństwa obarczone sporym ryzykiem: serwer nagle staje się punktem dostępu do prywatnego hosta.

Punkty kontrolne przy RemoteForward:

• czy w sshd_config jawnie określono politykę: AllowTcpForwarding, GatewayPorts,
• czy dopuszcza się scenariusze „serwer jako koncentrator tuneli” między maszynami użytkowników,
• czy prowadzone jest logowanie / monitoring portów zdalnych otwieranych przez użytkowników (np. reguły Match i osobne logi).

Jeżeli serwer dopuszcza dowolne RemoteForward, a firewalle są skonfigurowane pod założenie „serwer nie wystawia nic poza SSH”, to mamy niespójność modelu – SSH potrafi ten model obejść.

DynamicForward i SOCKS – pełne proxy w jednym poleceniu

Tryb DynamicForward (-D) zamienia klienta SSH w serwer proxy SOCKS:

ssh -D 1080 admin@bastion

Po ustawieniu w przeglądarce (lub narzędziu) proxy SOCKS na 127.0.0.1:1080, cały ruch HTTP/HTTPS może być kierowany przez bastion. To potężny mechanizm do bezpiecznego dostępu do zasobów wewnętrznych z zaufanych stacji, ale również uniwersalna furtka do omijania filtrów sieciowych.

Kryteria użycia DynamicForward jako elementu „bunkra”:

• ruch proxy jest zamknięty do konkretnego bastionu, a nie do dowolnego hosta z SSH,
• stacje z dostępem do takiego proxy są objęte tą samą polityką bezpieczeństwa (AV, DLP, kontrola przeglądarek),
• jest jasna reguła: do jakich podsieci/prod‑środowisk ruch przez SOCKS jest dozwolony, a do jakich nie.

Jeżeli użytkownicy samodzielnie budują tunel SOCKS na prywatnych laptopach, a następnie łączą się nim do sieci produkcyjnej, ryzyko wycieku lub infekcji rośnie wykładniczo – tunel staje się w praktyce VPN-em bez żadnej polityki klienta.

Reguły w sshd_config dla tunelowania

Na serwerze minimum kontroli nad tunelowaniem to zestaw dyrektyw:

AllowTcpForwarding yes
PermitTunnel no
GatewayPorts no
X11Forwarding no

Ten zestaw nadal zezwala na klasyczne tunelowanie TCP, ale blokuje pseudo‑interfejsy tun/tap oraz przekazywanie X11. W środowiskach wysokiego ryzyka decyzja może być jeszcze ostrzejsza:

AllowTcpForwarding no
PermitOpen 127.0.0.1:5432 127.0.0.1:6379

W takim wariancie tunelowanie jest domyślnie wyłączone, a PermitOpen definiuje jedyne dozwolone kombinacje host:port. Można to dodatkowo zawęzić blokiem Match dla konkretnej grupy:

Match Group db-admins
    AllowTcpForwarding yes
    PermitOpen 127.0.0.1:5432

Jeśli konfiguracja sshd nie zawiera żadnych dyrektyw dotyczących tunelowania, trzeba założyć, że użytkownicy mogą dowolnie tworzyć niewidoczne z punktu widzenia firewalli kanały – „bunkier” w warstwie sieciowej jest wtedy iluzją.

SSH jako zamiennik VPN – ograniczenia i ryzyka

Częstym odruchem jest użycie SSH jako szybkiego VPN: „otworzę tunel i już mam dostęp”. To może być dopuszczalne w małej, dobrze rozumianej infrastrukturze, ale w środowiskach regulowanych wymaga rygorystycznych kryteriów:

• czy klient SSH na stacji użytkownika jest zarządzany (konfiguracja centralna, wymuszone opcje),
• czy istnieje dokument opisujący, w jakich przypadkach SSH‑tunnel jest dozwolony zamiast pełnego VPN,
• czy zdalny dostęp przez SSH jest widoczny w tym samym systemie logów i alertów co ruch VPN,
• czy jest mechanizm szybkiego odcięcia tuneli (np. blokada konta w AD/LDAP skutkująca natychmiastowym przerwaniem sesji SSH).

Jeśli w praktyce SSH pełni rolę de facto VPN dla części osób, a nikt poza nimi nie potrafi tego opisać, mamy rozjazd między rzeczywistą a deklarowaną architekturą bezpieczeństwa. W razie incydentu trudniej wskazać, którą „ścieżką” ruch wszedł do środka.

Konfiguracja klienta SSH – bunkier na stacji użytkownika

Bezpieczny serwer SSH traci na wartości, jeśli klient po drugiej stronie jest przypadkowo skonfigurowany, a klucze leżą rozsiane po wielu katalogach i urządzeniach. ~/.ssh/config to miejsce, w którym można uporządkować dostęp i jednocześnie ograniczyć powierzchnię błędu człowieka.

Plik config – centralne zasady dla użytkownika

Dobrą praktyką jest definicja hostów z jasno opisanymi parametrami, zamiast ręcznego wpisywania długich poleceń. Przykład uporządkowanej konfiguracji:

Host bastion-prod
    HostName bastion.example.com
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519_admin
    IdentitiesOnly yes
    ForwardAgent no
    ServerAliveInterval 60
    ServerAliveCountMax 3

Host db-prod
    HostName db.internal.local
    User dbadmin
    ProxyJump bastion-prod
    IdentityFile ~/.ssh/id_ed25519_db
    IdentitiesOnly yes
    ForwardAgent no

Punkty kontrolne po stronie klienta:

• czy do każdego środowiska używany jest konkretny, opisany wpis Host,
• czy IdentityFile wskazuje jednoznaczny klucz, zamiast polegania na liście wszystkich możliwych kluczy,
• czy domyślnie blokowane jest ForwardAgent, a włączane tylko tam, gdzie jest naprawdę konieczne.

Jeżeli użytkownicy regularnie łączą się komendami typu ssh root@IP-serwera z ręcznym podawaniem parametrów, trudno mówić o przewidywalnym modelu dostępu. Każde wpisane „na pamięć” IP to potencjalny błąd i brak dokumentacji.

Ograniczenie agentów i kluczy – IdentitiesOnly i ControlMaster

Standardowy klient SSH potrafi wysłać do serwera wiele kluczy po kolei, zanim trafi na właściwy. To z jednej strony wygoda, z drugiej – wyciek informacji (serwer widzi zestaw używanych kluczy). Dyrektywa:

IdentitiesOnly yes

zmusza klienta, by używał wyłącznie kluczy wymienionych w IdentityFile lub podanych w linii komend. Przy kilku kluczach na jednym koncie to często minimum.

Warto zweryfikować również użycie trwałych połączeń (ControlMaster, ControlPersist). Z jednej strony zmniejszają liczbę autentykacji, z drugiej – wydłużają życie pojedynczej sesji, co ma znaczenie przy polityce blokad i wymuszonych przerw.

Host *
    ControlMaster auto
    ControlPath ~/.ssh/ctl-%r@%h:%p
    ControlPersist 5m

Jeśli sesje kontrolne utrzymują się godzinami lub dniami, a centralny system bezpieczeństwa liczy tylko liczbę logowań, to raporty o „wejściach” do środowiska są zafałszowane – wejście mogło mieć miejsce wiele godzin wcześniej.

Integracja z menedżerami kluczy i agentami systemowymi

Na stacjach roboczych użytkowników często działa kilka warstw: agent SSH (ssh-agent lub gpg-agent), menedżer kluczy systemu (np. GNOME Keyring, macOS Keychain), czasem narzędzia korporacyjne. W audycie trzeba odpowiedzieć na trzy pytania:

• kto faktycznie przechowuje klucz (plik na dysku, moduł HSM, TPM, inteligentna karta),
• kiedy i jak użytkownik musi się uwierzytelnić, by klucz został użyty (hasło do klucza, PIN, logowanie do systemu),
• jak długo „odblokowany” klucz jest aktywny w agencie (lifetime).

Dobrym kompromisem jest skonfigurowanie agenta z ograniczonym czasem życia klucza, np.:

ssh-add -t 3600 ~/.ssh/id_ed25519_admin

Jeżeli użytkownicy mają stale odblokowane klucze w agentach, a ich sesje trwają w nieskończoność, fizyczne przejęcie stacji roboczej niemal od razu oznacza kompromitację serwerów zdalnych.

Skalowanie SSH – bastiony, jump hosty i segmentacja środowisk

Przy kilku serwerach bezpośrednie logowanie po SSH bywa wystarczające. W większych infrastrukturach taki model przeradza się w chaos adresów i kluczy. Wtedy wchodzi rola bastionów (jump hostów) jako kontrolowanych punktów wejścia.

Bastion jako jedyna brama administracyjna

Model docelowy: wszystkie serwery produkcyjne akceptują ruch SSH wyłącznie z jednego (lub kilku redundatnych) bastionów. Administratorzy łączą się najpierw na bastion, a dopiero z niego przechodzą dalej. Firewall blokuje próby połączeń SSH z innych źródeł.

Kryteria oceny bastiona:

• czy jest odizolowany sieciowo od zwykłych segmentów użytkowników,
• czy logowanie na bastion jest silniej zabezpieczone niż na inne serwery (MFA, krótszy timeout sesji),
• czy na bastionie jest centralne logowanie komend (np. tlog, auditd, rejestrowanie sesji),
• czy na bastionie zabronione jest dalsze tunelowanie do Internetu (żeby nie zrobił się z niego „tunel w tunelu”).

Jeśli produkcja jest formalnie „chroniona”, ale każdy administrator ma bezpośredni SSH do serwerów z laptopa, a bastion istnieje tylko w dokumentacji, to realne bezpieczeństwo zależy wyłącznie od dyscypliny poszczególnych osób.

ProxyJump i ProxyCommand – jeden standardowy skok

Nowe wersje OpenSSH preferują ProxyJump (-J) zamiast ręcznego tunelowania:

ssh -J admin@bastion-prod admin@db-prod

W połączeniu z konfiguracją klienta:

Host bastion-prod
    HostName bastion.example.com
    User admin

Host *.prod.internal
    User admin
    ProxyJump bastion-prod

administrator uruchamia tylko ssh db01.prod.internal, a reszta dzieje się automatycznie. Pozwala to uniknąć „łańcuchów” SSH zestawianych ręcznie oraz ujednolica trasę dostępu.

Punkty kontrolne dla użycia ProxyJump:

• czy wszystkie połączenia do środowiska krytycznego wymuszają skok przez bastion (reguły DNS, firewall, polityka klienta),
• czy w konfiguracji klienta nie ma wyjątków typu Host * Prod z pominięciem ProxyJump,
• czy bastion loguje informacje o tym, do jakich hostów wewnętrznych użytkownik się przekierował.

Jeśli nie da się z logów bastiona odtworzyć, kto i kiedy łączył się dalej do poszczególnych serwerów, rola bastiona jako „bunkra audytowego” jest w praktyce iluzoryczna.

Przy audycie konfiguracji często wychodzą obejścia: ręczne wpisywanie adresów IP, alternatywne konta na serwerach, osobne „tymczasowe” bastiony. Jeśli użytkownik potrafi dotrzeć do produkcji inną ścieżką niż przez oficjalny jump host, segmentacja jest tylko pozorna. Minimum to spójność między konfiguracją DNS, regułami zapór i politykami klienta SSH – wszystkie trzy warstwy muszą wymuszać ten sam kierunek ruchu.

Segmentacja środowisk – osobne bramy dla różnych stref

W rozbudowanych instalacjach pojedynczy bastion dla wszystkiego kończy się tłokiem i konfliktem wymagań. Inne zasady obowiązują dla systemów developerskich, inne dla produkcji z danymi wrażliwymi. Rozsądniejsze jest podzielenie infrastruktury na kilka stref z odrębnymi punktami wejścia – np. bastion dla dev/test, osobny dla produkcji, osobny dla segmentu z systemami o najwyższej krytyczności.

Przy projektowaniu takiej segmentacji przydaje się krótka lista kryteriów:

• czy każda strefa ma jasno zdefiniowany bastion i osobne reguły dostępu,
• czy ten sam użytkownik ma inne uprawnienia w zależności od strefy (np. tylko odczyt w prod, pełna administracja w test),
• czy różne strefy można łatwo od siebie odciąć w sytuacji incydentu (osobne grupy firewalli, ACL, polityki routingu).

Jeśli jeden kompromitowany bastion otwiera drogę zarówno do środowiska testowego, jak i do krytycznych systemów finansowych, to segmentacja istnieje wyłącznie w slajdach prezentacji. Punkt kontrolny: czy da się „spalić” pojedynczą strefę (zablokować jej bastion) bez zatrzymywania całej firmy.

Monitorowanie i korelacja logów – bastion jako czarna skrzynka

Bastion pełni rolę nie tylko bramy, ale też rejestratora ruchu administracyjnego. Bez centralnego zbierania i korelowania logów trudno potem odpowiedzieć na proste pytanie: „kto był na tym serwerze 12 dni temu i co robił”. Minimum to wysyłanie dzienników SSH z bastionu do zewnętrznego systemu SIEM lub log management, z nienadmienialną, odporną na manipulacje retencją.

Przy konfiguracji logowania dobrze jest rozróżnić kilka poziomów informacji: logi uwierzytelnienia (kto się zalogował), logi kanałów (do jakiego hosta dalej poszedł ruch, przez jakie porty), oraz – tam gdzie to wymagane – logi wykonywanych komend lub pełnych sesji. Im wyższa krytyczność systemu, tym więcej szczegółów powinno lądować w rejestrach. Sygnałem ostrzegawczym jest sytuacja, w której jedynym śladem działania administratora jest pojedynczy wpis „Accepted publickey for user” w logu bastiona.

Jeśli ścieżka: użytkownik → bastion → serwer docelowy jest dobrze opisana w logach, łatwiej ocenić skalę incydentu i ograniczyć jego zasięg. Jeśli nie, każde naruszenie dostępu do klucza SSH kończy się długim dochodzeniem opartym na domysłach.

Bezpieczne SSH to wynik sumy wielu drobnych decyzji: od polityki haseł i kluczy, przez twardą konfigurację sshd, po sposób, w jaki użytkownicy korzystają z bastionów i tuneli. Tam, gdzie te elementy tworzą spójny model – z jasnymi rolami, segmentacją i rejestrowaniem działań – SSH staje się przewidywalną, kontrolowaną bramą. Tam, gdzie dominuje improwizacja i wyjątki od reguł, każdy nowy klucz lub serwer powiększa tylko powierzchnię ryzyka.

Najczęściej zadawane pytania (FAQ)

Jak bezpiecznie skonfigurować SSH na serwerze wystawionym do Internetu?

Minimum bezpieczeństwa to kilka konkretnych ustawień w /etc/ssh/sshd_config: wyłącz logowanie roota (PermitRootLogin no), wyłącz uwierzytelnianie hasłem dla kont administracyjnych (PasswordAuthentication no), wymuś logowanie kluczem oraz ogranicz liczbę prób logowania (MaxAuthTries, MaxStartups, MaxSessions). To zestaw absolutnego „must have” dla każdego serwera dostępnego z sieci publicznej.

Kolejne punkty kontrolne to: aktualna wersja OpenSSH (bez znanych podatności), usunięte lub zablokowane domyślne konta (admin, test, user, guest) oraz poprawnie działające logowanie zdarzeń do sysloga. Jeśli którykolwiek z tych punktów nie jest spełniony, serwer nie spełnia minimum bezpieczeństwa i wymaga pilnej korekty, zanim zostanie uznany za produkcyjny.

Czy zmiana portu SSH z 22 na inny naprawdę zwiększa bezpieczeństwo?

Zmiana portu z 22 na niestandardowy (tzw. security by obscurity) nie jest środkiem pierwszej linii, ale obniża „szum tła”: w logach pojawia się mniej prób brutalnego łamania haseł z losowych botów. To ułatwia przegląd logów i wychwycenie realnych incydentów. Nie jest to jednak substytut silnej konfiguracji.

Jeżeli serwer nadal akceptuje logowanie hasłem, zezwala na logowanie root z Internetu i nie ma limitów prób logowania, to zmiana portu niczego istotnego nie rozwiązuje – to tylko kosmetyka. Bez wyłączenia haseł i wymuszenia kluczy, taka zmiana to sygnał ostrzegawczy, że priorytetem jest pozorne „obejście problemu”, a nie jego usunięcie.

Czy logowanie kluczem SSH jest bezpieczniejsze niż hasło i jak je poprawnie wdrożyć?

Tak, logowanie kluczem publicznym jest wielokrotnie bezpieczniejsze niż hasło – pod warunkiem, że klucz prywatny jest chroniony passphrase. Atakujący nie może „zgadywać” klucza tak jak hasła przez sieć; musi najpierw wykraść plik klucza, a dopiero potem próbować go łamać offline. To podnosi koszt ataku i wymusza inne wektory (np. zainfekowanie stacji roboczej admina).

Przy wdrażaniu kluczy punktami kontrolnymi są: generowanie kluczy na zaufanej maszynie, użycie silnej passphrase, ograniczenie zakresu użycia klucza po stronie serwera (dyrektywy command=, from=, no-port-forwarding w authorized_keys) oraz wyłączenie haseł przynajmniej dla kont uprzywilejowanych. Jeśli klucz jest bez passphrase i dopuszczony „wszędzie i do wszystkiego”, w razie kradzieży staje się równoważny hasłu zapisanym w pliku tekstowym.

Jak rozpoznać po logach, że mój serwer SSH jest atakowany?

Podstawowy punkt kontrolny to zawartość /var/log/auth.log (Debian/Ubuntu) lub /var/log/secure (RHEL/CentOS). Charakterystyczne oznaki to setki wpisów typu Failed password for invalid user admin albo próby logowania do kont root, user, test z różnych adresów IP. Na serwerze wystawionym na port 22 taki „szum” pojawia się zwykle w ciągu kilku minut od podłączenia do Internetu.

Sygnalłem ostrzegawczym wyższego poziomu są udane logowania (Accepted password / Accepted publickey) dla kont, które nie powinny być używane, lub z adresów, których nie rozpoznajesz. Jeśli obserwujesz brak jakichkolwiek nieudanych prób przy działającym SSH, to także jest czerwone światło – może oznaczać błędną konfigurację logowania lub wyłączone logi, a nie brak ataków.

Czy wystawianie SSH bez VPN jest bezpieczne, jeśli mam dobre hasło?

Samo „dobre hasło” nie spełnia kryterium bezpieczeństwa dla usług administratorskich wystawionych wprost do Internetu. Bez VPN SSH staje się jedyną barierą; jeśli przyjmuje hasła i pozwala na logowanie roota, poziom ryzyka zbliża się do wystawionego RDP bez dodatkowych zabezpieczeń. Boty będą testować hasło tak długo, aż znajdą słabość – czy to w haśle, czy w konfiguracji.

Jeśli SSH musi być dostępne bezpośrednio, minimum to: wyłączone hasła (tylko klucze), zablokowany root, ograniczenie dostępu po IP firewallem, aktualna wersja serwera oraz aktywne monitorowanie logów. Jeżeli któregokolwiek z tych elementów brakuje, nie można mówić o rozsądnie zarządzanym ryzyku – to raczej scenariusz „działa, dopóki mamy szczęście”.

Jakie są najczęstsze błędy w konfiguracji SSH, które widzi audytor?

Najczęściej pojawiają się: domyślna konfiguracja sshd_config bez dodatkowych dyrektyw bezpieczeństwa, logowanie roota z Internetu, pełne uwierzytelnianie hasłem dla wszystkich kont, brak limitów prób logowania oraz brak jakiejkolwiek analizy logów. Dodatkowym problemem są pozostawione domyślne konta (admin, test) i brak polityki tworzenia oraz rotacji kluczy.

Jeżeli przy audycie jedynym „testem” SSH jest sprawdzenie, czy administrator potrafi się zalogować, to wyraźny sygnał ostrzegawczy, że priorytetem jest wygoda operacyjna, a nie kontrola ryzyka. Dopiero po przejściu listy kryteriów (konfiguracja, konta, logi, limity, aktualizacje) można uczciwie ocenić, czy SSH pełni rolę bunkra, czy raczej niepilnowanej furtki.

Czy komunikat „REMOTE HOST IDENTIFICATION HAS CHANGED” oznacza atak na SSH?

Taki komunikat oznacza, że fingerprint klucza hosta zapisany w ~/.ssh/known_hosts nie zgadza się z tym, który zgłasza serwer. W wielu przypadkach to efekt legalnej zmiany (np. reinstalacja systemu, wymiana serwera), ale z perspektywy bezpieczeństwa zawsze jest to punkt kontrolny wymagający wyjaśnienia. Bez weryfikacji akceptowanie nowego klucza „w ciemno” otwiera drogę do ataku typu man-in-the-middle.

Jeżeli adres IP, domena czy ścieżka sieciowa mogły zostać przechwycone lub podmienione (np. publiczne Wi-Fi, niezaufana sieć), traktuj taki komunikat jako sygnał ostrzegawczy wysokiego poziomu. Dopóki administrator nie potwierdzi innym kanałem (np. telefonicznie, przez VPN), że fingerprint faktycznie się zmienił, każde połączenie może być podsłuchiwane lub modyfikowane przez atakującego.

Kluczowe Wnioski

• SSH jest jednocześnie główną furtką i bunkrem: przy konfiguracji „domyślne + hasła” bezpieczeństwo zależy wyłącznie od szczęścia, natomiast twarda konfiguracja (klucze, ograniczone IP, brak roota) zamienia je w realną barierę dla atakującego.
• Absolutne minimum bezpieczeństwa to: aktualna wersja serwera SSH, wyłączone logowanie root, brak haseł dla kont administracyjnych, logowanie wyłącznie kluczami, usunięte domyślne konta oraz ustawione limity prób logowania i sesji – jeśli któryś z tych punktów zawodzi, mamy do czynienia z luką projektową, nie „stylem pracy admina”.
• Sygnały ostrzegawcze, które od razu dyskwalifikują konfigurację „bunkra”, to m.in. możliwość logowania jako root z Internetu, włączone uwierzytelnianie hasłem dla wszystkich, niczym nieograniczony port 22 oraz domyślny, niemodyfikowany sshd_config; jeśli widocznych jest kilka takich objawów, priorytetem staje się natychmiastowe utwardzenie SSH.
• Z punktu widzenia audytu nie wystarcza, że „admin się zaloguje”: punktami kontrolnymi są spójność z polityką bezpieczeństwa, minimalna powierzchnia ataku i możliwość prześledzenia działań użytkowników w logach; jeśli jedynym testem jest sprawdzenie logowania, organizacja premiuje wygodę ponad kontrolę ryzyka.
• Gdy SSH jest jedyną bezpośrednio wystawioną usługą administracyjną (bez poprzedzającego VPN), jego konfiguracja staje się odpowiednikiem konfiguracji VPN: akceptowanie haseł i roota w takim scenariuszu powinno być oceniane równie surowo jak publiczne RDP bez dodatkowych zabezpieczeń.