Secure Shell (SSH) to fundamentalny protokół dla każdego administratora sieci i systemów. Umożliwia bezpieczne zdalne logowanie, wykonywanie poleceń oraz przesyłanie plików w sposób szyfrowany, eliminując zagrożenia charakterystyczne dla przestarzałych protokołów takich jak Telnet czy rlogin. W ramach szóstej prezentacji z cyklu Administracja Sieci Komputerowych skupimy się na trzech filarach: zrozumieniu mechaniki kryptograficznej (tak aby administrator wiedział, co dokładnie chroni), praktycznym hardeningu serwera SSH w środowisku produkcyjnym oraz zaawansowanym tunelowaniu ruchu sieciowego. Każdy z tych tematów jest kluczowy w codziennej pracy inżyniera sieciowego - od zabezpieczenia dostępu do routerów i switchy, przez automatyzację z Ansible, aż po bezpieczne połączenia z bazami danych za firewallem. Warsztat został zaprojektowany według zasady "show, don't tell": każde zagadnienie jest poparte demonstracją krok po kroku, a troubleshooting stanowi integralną część materiału.

Celem tego warsztatu jest wyposażenie uczestnika w kompleksową wiedzę na temat bezpiecznego zdalnego dostępu. Współczesna infrastruktura IT rzadko pozwala na fizyczny dostęp do każdego serwera - administrator musi łączyć się zdalnie, często przez publiczną sieć Internet. SSH jest narzędziem, które umożliwia to bezpiecznie, ale tylko pod warunkiem prawidłowej konfiguracji. Niestety, domyślne ustawienia SSH są często zbyt liberalne dla środowiska produkcyjnego. Warsztat pokaże, jak przejść od domyślnej, hasłowej konfiguracji do w pełni zabezpieczonego dostępu kluczowego z ograniczeniami grup, blokadą roota i szyfrowanymi tunelami. Nauczymy się również diagnozować najczęstsze problemy - od błędów permisji plików kluczy, przez konflikty known_hosts, po blokady firewalla blokujące tunele SSH. Wiedza ta jest uniwersalna: dotyczy zarówno serwerów Linux, jak i urządzeń sieciowych (Cisco, MikroTik, Juniper) obsługujących SSH.

Prezentacja została podzielona na cztery logiczne bloki, które prowadzą uczestnika od podstaw teoretycznych, przez konfigurację produkcyjną, aż po zaawansowane techniki tunelowania i rozwiązywanie problemów. Pierwsza część (teoretyczna, ok. 20 minut) wyjaśnia, co dzieje się "pod maską" podczas nawiązywania połączenia SSH - jakie algorytmy kryptograficzne są używane, w jakiej kolejności i dlaczego tak ważny jest wybór odpowiedniego typu klucza. Druga część (ok. 15 minut) to sekcja hardeningu - pokazująca, jak zamienić domyślnie otwarty serwer SSH w twierdzę. Trzecia część (ok. 25 minut) to najbardziej zaawansowana technicznie sekcja - tunele SSH pozwalające na kreatywne ominięcie ograniczeń sieciowych. Czwarta część (ok. 30 minut) to intensywne laboratorium, w którym każdy uczestnik samodzielnie wygeneruje klucze, skonfiguruje klienta i serwer, przetestuje tunele i nauczy się diagnozować najczęstsze błędy. Łączny czas: ok. 90 minut z przerwą.

Zanim powstał SSH, administratorzy systemów Unix polegali na Telnecie i rloginie. Telnet, stworzony w 1983 roku, był protokołem tekstowym, który przesyłał wszystkie dane - w tym nazwy użytkownika i hasła - w postaci niezaszyfrowanej. Każdy, kto miał dostęp do sieci (np. poprzez narzędzie takie jak tcpdump czy Wireshark), mógł przechwycić dane logowania. rlogin, choć wygodniejszy (wspierał zaufanie między hostami), borykał się z tymi samymi problemami - brakiem szyfrowania i podatnością na fałszowanie adresów IP. Dopiero Tatu Ylönen, fiński programista, po wykryciu ataku sniffingowego na swojej uczelni, stworzył pierwszą wersję SSH (SSH-1) w 1995 roku. Protokół ten szyfrował całą sesję, uwierzytelniał serwer i klienta oraz zapewniał integralność transmisji. W 2006 roku grupa robocza IETF opublikowała SSH-2 (RFC 4251-4256), który jest obecnie standardem. SSH-2 wprowadził silniejsze algorytmy kryptograficzne, obsługę tunelowania oraz oddzielenie warstwy transportowej od uwierzytelniania.

Protokół SSH-2 został zaprojektowany modularnie, z rozdzieleniem odpowiedzialności na trzy osobne warstwy. Transport Layer odpowiada za ustanowienie bezpiecznego kanału komunikacji między klientem a serwerem: negocjuje algorytmy szyfrowania symetrycznego (AES, ChaCha20), funkcje skrótu (HMAC-SHA2) i opcjonalną kompresję. Na tym etapie generowany jest również wspólny klucz sesji przy użyciu protokołu Diffiego-Hellmana. Po ustanowieniu bezpiecznego kanału następuje warstwa uwierzytelniania (Authentication Layer), w której klient udowadnia swoją tożsamość. SSH-2 wspiera wiele metod uwierzytelniania: hasło (password), klucz publiczny (publickey), GSSAPI (Kerberos), keyboard-interactive (np. odpowiedzi na challenge). Ostatnia warstwa - Connection Layer - odpowiada za multipleksowanie: jedno połączenie SSH może obsługiwać jednocześnie wiele "kanałów" - np. interaktywną sesję shell, tunel portów, transfer plików SCP czy SFTP. Dzięki temu każde połączenie SSH jest bardzo efektywne.

W protokole SSH wykorzystuje się oba rodzaje szyfrowania, każde do innego celu. Szyfrowanie symetryczne, w którym ten sam klucz służy do zaszyfrowania i odszyfrowania danych, jest bardzo szybkie - nawet dla gigabajtowych strumieni danych. W SSH używa się go do szyfrowania całej sesji po ustanowieniu połączenia (szyfr sesyjny). Typowe algorytmy to AES-256 w trybie GCM (Galois/Counter Mode) oraz ChaCha20-Poly1305 - oba zapewniają również uwierzytelnianie danych. Problemem jest jednak bezpieczne uzgodnienie wspólnego klucza symetrycznego przez niezaufaną sieć. Do tego właśnie służy szyfrowanie asymetryczne - protokół Diffiego-Hellmana (lub jego wariant na krzywych eliptycznych, ECDH) pozwala dwóm stronom uzgodnić wspólny sekret bez przesyłania go jawnie. W SSH wykorzystuje się również podpisy cyfrowe (asymetryczne) do uwierzytelniania serwera (host key) i klienta (klucz publiczny użytkownika). Podsumowując: asymetryczne = bezpieczne uzgodnienie klucza i uwierzytelnienie; symetryczne = szybkie szyfrowanie danych sesji.

Protokół Diffiego-Hellmana jest fundamentem bezpieczeństwa SSH. Działa w następujący sposób: klient i serwer uzgadniają dwa parametry: liczbę pierwszą p oraz generator g. Każda strona losuje swój prywatny klucz (a dla klienta, b dla serwera), oblicza wartość publiczną (g^a mod p i g^b mod p) i wysyła ją drugiej stronie. Następnie każda ze stron podnosi otrzymaną wartość do swojego klucza prywatnego, uzyskując ten sam sekret: g^(ab) mod p. Atakujący przechwytujący g^a i g^b nie jest w stanie obliczyć g^(ab) bez znajomości a lub b - to jest właśnie problem logarytmu dyskretnego. W nowoczesnych implementacjach SSH stosuje się ECDH - wariant na krzywych eliptycznych, który oferuje ten sam poziom bezpieczeństwa przy znacznie krótszych kluczach (np. 256-bit ECC odpowiada 3072-bit RSA/DH). Co istotne, SSH używa również HMAC - funkcji skrótu z kluczem - która zapewnia integralność i autentyczność każdego pakietu, uniemożliwiając modyfikację danych w locie.

Para kluczy (key pair) to fundament uwierzytelniania w SSH bez użycia hasła. Klucz prywatny (private key) jest przechowywany na maszynie administratora i stanowi cyfrowy odpowiednik fizycznego klucza do serwerowni - musi być chroniony hasłem (passphrase) i odpowiednimi prawami dostępu (chmod 600). Klucz publiczny (public key) można bezpiecznie kopiować na serwery - dodaje się go do pliku ~/.ssh/authorized_keys na serwerze. Proces uwierzytelniania wygląda następująco: serwer generuje losowe wyzwanie (ciąg bajtów), klient podpisuje je swoim kluczem prywatnym i odsyła podpis, a serwer - mając klucz publiczny klienta - weryfikuje, czy podpis jest prawidłowy. Jeśli tak, klient zostaje uwierzytelniony. Zauważmy: klucz prywatny NIGDY nie opuszcza maszyny klienta. Nawet gdyby atakujący przechwycił podpisane wyzwanie, nie jest w stanie odtworzyć klucza prywatnego - może co najwyżej zweryfikować, że podpis jest poprawny. Analogicznie działa host key serwera - przy pierwszym połączeniu SSH zapamiętuje odcisk klucza serwera w pliku ~/.ssh/known_hosts, co chroni przed atakami MITM.

Wybór algorytmu klucza ma znaczenie zarówno dla bezpieczeństwa, jak i wydajności. RSA przez dekady był standardem, ale wraz ze wzrostem mocy obliczeniowej minimalny bezpieczny rozmiar klucza wzrósł z 1024 do 3072 (a zalecane 4096) bitów. Generowanie tak dużego klucza jest powolne, a sama operacja podpisywania - kosztowna obliczeniowo. ECDSA (Digital Signature Algorithm na krzywych eliptycznych) jest znacznie szybszy - klucz 256-bit ECDSA zapewnia bezpieczeństwo porównywalne z 3072-bit RSA. Ma jednak wady: jest wrażliwy na jakość generatora liczb losowych (słabe RNG może ujawnić klucz prywatny) oraz opiera się na krzywych NIST, którym niektórzy eksperci nie ufają (podejrzenia o backdoor). Ed25519, zaprojektowany przez Daniela J. Bernsteina (twórcy Curve25519), eliminuje te problemy: używa stałego czasu wykonania (odporny na ataki timingowe), jest niewrażliwy na słabe RNG (deterministyczne podpisy), a jego klucz publiczny ma zaledwie 32 bajty. Od 2024 roku Ed25519 jest domyślnym algorytmem w OpenSSH. Używaj go wszędzie tam, gdzie to możliwe.

Host key to mechanizm obrony przed atakami Man-in-the-Middle w SSH. Gdy serwer SSH jest instalowany po raz pierwszy (np. apt install openssh-server na Debianie/Ubuntu), automatycznie generowane są pary kluczy hosta dla obsługiwanych algorytmów. Pliki te znajdują się w katalogu /etc/ssh/ i mają ściśle określone prawa dostępu (dla kluczy prywatnych: 600, dla publicznych: 644). Gdy klient łączy się z serwerem po raz pierwszy, SSH wyświetla odcisk (fingerprint) klucza publicznego serwera i pyta: "Are you sure you want to continue connecting?". Jeśli odpowiedź brzmi "yes", odcisk zostaje zapisany w pliku ~/.ssh/known_hosts na kliencie. Przy każdym kolejnym połączeniu SSH porównuje odcisk klucza serwera z zapisanym w known_hosts. Jeśli klucz serwera się zmienił (np. reinstalacja systemu, podmiana serwera), SSH ostrzega i odrzuca połączenie - to sygnał, że ktoś mógł przechwycić ruch. Weryfikacja odcisku powinna być przeprowadzana bezpiecznym kanałem (np. telefonicznie, przez szyfrowany komunikator) - nigdy przez samo połączenie SSH.

Oba pliki pełnią kluczowe role w ekosystemie SSH. known_hosts po stronie klienta działa jako "książka adresowa zaufanych serwerów". Gdy klient łączy się z serwerem, SSH wyszukuje wpis w known_hosts: jeśli znajdzie dopasowanie dla danego hosta i klucza - połączenie jest kontynuowane bez pytania; jeśli klucz się różni - SSH ostrzega i przerywa połączenie; jeśli hosta nie ma w known_hosts - pyta użytkownika o akceptację. Dozwolone są różne formaty wpisów: haszowane (dla prywatności) i zwykłe (z czytelną nazwą hosta). authorized_keys po stronie serwera to lista zaufanych kluczy publicznych. Każda linia to jeden klucz, z opcjonalnymi ograniczeniami (np. command=, from=, no-agent-forwarding). Plik ten jest czytany przez sshd podczas uwierzytelniania metodą publickey. Ważne: jeśli prawa dostępu do authorized_keys lub całego katalogu .ssh są zbyt otwarte (np. grupa lub inni mają prawo zapisu), SSH zignoruje ten plik z błędem "Authentication refused: bad ownership or modes". To częsty problem podczas kopiowania kluczy między kontami.

Przejście z RSA na krzywe eliptyczne w SSH to nie fanaberia, ale konieczność techniczna. Porównajmy: klucz RSA 4096 bitów zapewnia bezpieczeństwo na poziomie około 150 bitów (w kryptografii symetrycznej). Klucz Ed25519 (256-bitowa krzywa) zapewnia bezpieczeństwo 128 bitów - czyli więcej niż RSA 3072. Różnica w wydajności jest drastyczna: wygenerowanie pary Ed25519 zajmuje ułamek sekundy, podczas gdy RSA 4096 może trwać kilka sekund. Operacja podpisywania na Ed25519 jest około 10-20 razy szybsza niż na RSA 4096. Co więcej, Ed25519 jest deterministyczny - ten sam podpis dla tych samych danych i tego samego klucza zawsze wygląda identycznie, co eliminuje klasę ataków związanych ze słabym generatorem liczb losowych. Dodatkowo Ed25519 używa krzywej Bernsteina (Curve25519), która została zaprojektowana tak, aby uniknąć pułapek patentowych i kontrowersji związanych z krzywymi NIST. W praktyce: jeśli twój serwer SSH obsługuje Ed25519 (wersja OpenSSH >= 6.5), nie ma powodu, by używać czegokolwiek innego.

Środowisko produkcyjne różni się zasadniczo od laboratoryjnego czy domowego. Gdy serwer SSH jest wystawiony na publiczny Internet, boty znajdują go w ciągu kilku minut od uruchomienia. Logi syslog wypełniają się wpisami "Failed password for root" - to automatyczne skanery próbujące domyślnych haseł. W niektórych sieciach dzienna liczba prób logowania może sięgać kilkudziesięciu tysięcy. Domyślna konfiguracja SSH jest zaprojektowana z myślą o maksymalnej kompatybilności i wygodzie, a nie o maksymalnym bezpieczeństwie. Dlatego inżynier sieciowy musi świadomie ograniczyć dostęp: wyłączyć logowanie hasłem (zostawić tylko klucze), zablokować bezpośrednie logowanie na konto roota, ograniczyć dostęp do wybranych grup systemowych i zmienić domyślny port, aby zredukować szum z automatycznych skanerów. Pamiętaj: bezpieczeństwo to proces, nie stan. Hardening SSH to nie jednorazowa czynność, ale element regularnego przeglądu konfiguracji. Po każdej zmianie w sshd_config przetestuj konfigurację komendą sshd -t zanim zrestartujesz demona.

Plik /etc/ssh/sshd_config to centrum konfiguracyjne demona SSH (sshd). Każda linia to dyrektywa w formacie "Klucz Wartość". Komentarze zaczynają się od znaku #. Większość dyrektyw ma domyślne wartości, które są używane, jeśli nie są jawnie ustawione w pliku. Aby sprawdzić aktualną konfigurację, można użyć sshd -T (wyświetla efektywną konfigurację z uwzględnieniem domyślnych wartości). Przed wprowadzeniem zmian zawsze wykonaj sshd -t - to sprawdzi składnię pliku i ostrzeże o potencjalnych problemach. Krytyczna zasada bezpieczeństwa: nigdy nie zamykaj jedynej aktywnej sesji SSH bez uprzedniego przetestowania nowej konfiguracji. Zawsze miej otwarte co najmniej dwa połączenia (lub dostęp do konsoli out-of-band, np. iDRAC, IPMI, iLO). Jeśli po restarcie sshd konfiguracja okaże się błędna i zablokuje dostęp, możesz stracić kontakt z serwerem. W środowisku produkcyjnym warto użyć narzędzia typu sshguard lub fail2ban jako dodatkowej warstwy zabezpieczeń - ale nie zastępują one prawidłowej konfiguracji sshd_config.

PasswordAuthentication no to najważniejsza dyrektywa w hardeningu SSH. Wyłączenie logowania hasłem eliminuje całą klasę ataków: brute-force, słownikowe, zgadywanie haseł, ataki na słabe hasła użytkowników. Hasła są najsłabszym ogniwem w każdej architekturze bezpieczeństwa - użytkownicy wybierają słabe hasła, używają ich wielokrotnie, zapisują na karteczkach. Klucze SSH są znacznie bezpieczniejsze: mają długość setek bitów entropii i nie mogą być odgadnięte. Jednocześnie logowanie kluczem jest wygodniejsze - nie trzeba wpisywać hasła przy każdym połączeniu (zwłaszcza przy użyciu ssh-agent). Przed wprowadzeniem tej zmiany musisz bezwzględnie upewnić się, że twój klucz publiczny znajduje się w ~/.ssh/authorized_keys na serwerze. Jeśli wyłączysz hasła, a nie masz skonfigurowanego klucza - stracisz dostęp. Dlatego zawsze najpierw skopiuj klucz (ssh-copy-id), przetestuj logowanie kluczem, a dopiero potem wyłącz hasła. W środowisku, gdzie nie masz pewności co do kluczy, możesz zastosować etap przejściowy: zostaw PasswordAuthentication yes, ale ustaw AuthenticationMethods publickey,password - wymusi to obie metody jednocześnie.

Konto root (UID 0) istnieje na każdym systemie Unix/Linux, a jego nazwa jest znana każdemu potencjalnemu atakującemu. Blokada bezpośredniego logowania przez SSH na konto root to jedna z podstawowych zasad bezpieczeństwa. Dyrektywa PermitRootLogin przyjmuje kilka wartości: "yes" (zezwala na wszystko - NIGDY nie używaj w produkcji), "prohibit-password" (zezwala na logowanie kluczem, blokuje hasła), "without-password" (przestarzały alias prohibit-password), "forced-commands-only" (tylko wykonanie konkretnych komend z authorized_keys) i "no" (całkowita blokada). W środowisku produkcyjnym zaleca się PermitRootLogin no, a administratorzy logują się na swoje konta użytkownicze i używają sudo. Sudo zapewnia pełny audyt: każda komenda wykonana przez sudo jest logowana (kto, kiedy, jaką komendę), podczas gdy praca bezpośrednio na root maskuje te informacje. Wyjątkiem są systemy do zarządzania konfiguracją (Ansible, Puppet), które często wymagają dostępu root przez SSH - wtedy stosuje się PermitRootLogin prohibit-password z kluczem. Dodatkowo warto użyć dyrektywy "Match" w sshd_config aby zablokować root tylko z niektórych adresów IP lub tylko dla określonych grup.

AllowGroups i AllowUsers to dyrektywy sshd_config, które implementują listę kontroli dostępu (ACL) na poziomie demona SSH. Są one szczególnie przydatne w środowiskach, gdzie wielu użytkowników ma konta na serwerze, ale tylko niektórzy powinni mieć dostęp przez SSH. Na przykład: serwer plików Samba, na który logują się lokalnie użytkownicy przez FTP/SMB, ale SSH powinien być dostępny tylko dla administratorów. Tworzymy grupę "ssh-users", dodajemy do niej wyłącznie osoby z personelu IT, a w sshd_config ustawiamy AllowGroups ssh-users. Jeśli pracownik odchodzi z firmy, wystarczy usunąć go z grupy ssh-users - nie trzeba blokować całego konta ani modyfikować pliku authorized_keys. AllowUsers jest jeszcze bardziej restrykcyjne - wymienia konkretne nazwy użytkowników. Należy pamiętać, że AllowGroups i AllowUsers nie wykluczają się wzajemnie - można ich używać razem (wtedy użytkownik musi spełniać oba warunki). Ważne: te dyrektywy filtrują na etapie uwierzytelniania, więc nawet jeśli użytkownik ma klucz w authorized_keys, ale nie należy do dozwolonej grupy - logowanie zostanie odrzucone.

Zmiana domyślnego portu SSH z 22 na niestandardowy to kontrowersyjny zabieg. Z jednej strony: boty skanujące Internet w poszukiwaniu SSH koncentrują się na porcie 22 - zmiana portu natychmiast eliminuje 99% zautomatyzowanych ataków brute-force. Z drugiej strony: to "security through obscurity" - zaawansowany atakujący szybko znajdzie SSH skanując cały zakres portów. Mimo to, w praktyce zmiana portu ma sens: redukuje szum w logach, zmniejsza obciążenie serwera (mniej prób uwierzytelnienia do odrzucenia) i utrudnia pracę automatom. W środowisku produkcyjnym zmiana portu powinna być częścią szerszej strategii, a nie jedynym zabezpieczeniem. Wybierając nowy port, unikaj łatwo zgadywalnych wartości typu 2222, 22222, 8022 - lepiej użyć wysokiego portu (np. 51022). Pamiętaj o aktualizacji konfiguracji firewalla. Jeśli używasz narzędzi automatyzacji (Ansible, rsync, git przez SSH), musisz zaktualizować ich konfiguracje. W skali enterprise zmiana portu na wszystkich serwerach może być uciążliwa - warto rozważyć użycie SSH Gateway (bastion host) jako jedynego punktu wejścia zamiast zmiany portów na każdym serwerze.

Oprócz podstawowych dyrektyw (PasswordAuthentication, PermitRootLogin, AllowGroups, Port) istnieje szereg dodatkowych ustawień zwiększających bezpieczeństwo SSH. MaxAuthTries limituje liczbę prób logowania w ramach jednego połączenia - po przekroczeniu SSH zrywa połączenie, a w logach syslog pojawia się wpis "maximum authentication attempts exceeded". ClientAliveInterval w połączeniu z ClientAliveCountMax automatycznie zamyka sesje, w których klient przestał odpowiadać (np. awaria sieci, zawieszenie klienta). Bez tego wiszące sesje SSH mogą blokować zasoby serwera. OpenSSH od wersji 7.5 (2017) działa wyłącznie w trybie SSH-2 - protokół SSH-1 został całkowicie usunięty, więc nie ma potrzeby stosowania żadnej dodatkowej dyrektywy. X11Forwarding powinno być włączone tylko wtedy, gdy faktycznie potrzebujesz przekierowania aplikacji graficznych przez SSH - w przeciwnym razie stwarza niepotrzebne ryzyko. Warto również rozważyć dyrektywy takie jak LogLevel VERBOSE (szczegółowe logowanie wszystkich prób logowania), UsePAM yes (włączenie PAM - pozwala na dodatkowe metody uwierzytelniania, ale też potencjalnie zwiększa powierzchnię ataku) oraz PermitEmptyPasswords no (oczywiste, ale warto sprawdzić).

Powyższa konfiguracja stanowi wzorzec produkcyjny dla serwera SSH. Port 51022 (wysoki, niestandardowy) - redukuje automatyczne skany. Od wersji 7.5 OpenSSH obsługuje wyłącznie SSH-2 - protokół SSH-1 został całkowicie wyeliminowany. PermitRootLogin no całkowicie blokuje logowanie na konto root - administratorzy logują się na swoje konta i używają sudo. PasswordAuthentication no wymusza uwierzytelnienie kluczem, eliminując ataki brute-force na hasła. AuthenticationMethods publickey dodatkowo precyzuje, że tylko publickey jest dozwolone (odcina inne metody, jak keyboard-interactive). AllowGroups ssh-users ogranicza dostęp tylko do członków grupy ssh-users - to kolejna warstwa kontroli. MaxAuthTries 3 i MaxSessions 5 chronią przed przeciążeniem demona. ClientAliveInterval 300 i ClientAliveCountMax 2 zapewniają automatyczne czyszczenie porzuconych sesji po 10 minutach. X11Forwarding no wyłącza niepotrzebne ryzyko. LogLevel VERBOSE zapewnia szczegółowe logi w /var/log/auth.log. LoginGraceTime 30 ogranicza czas na uwierzytelnienie do 30 sekund - po tym czasie połączenie jest zamykane (zapobiega trzymaniu otwartych połączeń w stanie logowania). Pamiętaj o sshd -t przed restartem!

SSH Tunneling to jedna z najpotężniejszych (i często niedocenianych) funkcji SSH. Pozwala na bezpieczne przekierowanie ruchu TCP z jednego portu na lokalnej maszynie do dowolnego portu na zdalnej maszynie (lub odwrotnie), a wszystko to przez szyfrowane połączenie SSH. Wyobraź sobie, że masz bazę MySQL na serwerze produkcyjnym, która słucha tylko na localhost (127.0.0.1:3306) - dostęp z zewnątrz jest zablokowany firewallem. Dzięki SSH Tunneling możesz przekierować lokalny port (np. 13306) na swoim laptopie na zdalny port 3306 - a ruch przejdzie przez szyfrowany tunel SSH. Z poziomu klienta MySQL na laptopie łączysz się z localhost:13306, a faktycznie trafiasz do bazy na serwerze. Podobnie możesz tunelować ruch HTTP, RDP, VNC, a nawet cały ruch aplikacji przez SOCKS5 proxy. SSH Tunneling jest szczególnie przydatny w architekturach z bastion hostem (jump server) - zamiast otwierać wiele portów w firewallu, wystarczy jeden port SSH na bastionie, a przez niego tunelujemy ruch do wszystkich serwisów w sieci wewnętrznej.

Local Forwarding to najczęściej używany typ tunelowania SSH. Działa następująco: na maszynie klienta SSH otwiera port (local_port) i nasłuchuje na nim. Każde połączenie przychodzące na ten port jest przekazywane przez szyfrowany tunel SSH do serwera, a następnie z serwera do wskazanego remote_host:remote_port. Klient lokalny myśli, że łączy się z localhost:local_port - nie wie o istnieniu tunelu. To niezwykle przydatne, gdy chcesz uzyskać dostęp do usługi, która jest dostępna tylko z sieci wewnętrznej serwera SSH. Przykład: chcesz połączyć się z konsolą administracyjną routera (192.168.1.1:80), który jest dostępny tylko z sieci wewnętrznej twojego serwera. Używasz: ssh -L 8080:192.168.1.1:80 user@server, a następnie otwierasz w przeglądarce http://localhost:8080. Ruch: laptop -> localhost:8080 -> tunel SSH -> server -> 192.168.1.1:80. W odpowiedzi: router -> server -> tunel SSH -> laptop. Cała komunikacja między laptopem a serwerem jest szyfrowana. Flagi -N (no command) i -f (background) są przydatne, gdy chcesz utrzymać tunel bez otwierania sesji shell.

To jeden z najbardziej praktycznych scenariuszy użycia Local Forwarding. W środowisku produkcyjnym serwer bazy danych MySQL (lub PostgreSQL) często słucha wyłącznie na interfejsie loopback (127.0.0.1:3306), a firewall blokuje wszystkie porty poza SSH. Administrator musi czasami jednak połączyć się z bazą - do diagnostyki, optymalizacji zapytań czy awaryjnych zmian. Zamiast otwierać port 3306 w firewallu (co zwiększa powierzchnię ataku), używamy SSH Tunneling. Na laptopie administratora wykonujemy: ssh -L 13306:127.0.0.1:3306 admin@serwer-produkcyjny.pl -Nf. Teraz na laptopie nasłuchuje port 13306. Łączymy się klientem MySQL: mysql -h 127.0.0.1 -P 13306 -u root -p. Ruch: laptop -> localhost:13306 -> ssh tunnel -> serwer:3306. Wszystkie zapytania SQL są szyfrowane przez SSH. Co ważne, remote_host to 127.0.0.1 z perspektywy serwera SSH - czyli odnosimy się do localhosta na samym serwerze. Gdyby baza działała na innym hoście w sieci wewnętrznej (np. 10.0.0.5:3306), użyłbyś: ssh -L 13306:10.0.0.5:3306 admin@serwer-produkcyjny.pl. To samo podejście działa dla innych baz danych, Redis, MongoDB, a nawet interfejsów API.

W praktyce rzadko tunelujemy tylko jeden port - często potrzebujemy dostępu do kilku usług jednocześnie. SSH pozwala na wielokrotne użycie flagi -L w jednym poleceniu. Na przykład: ssh -L 8080:web.internal:80 -L 3306:db.internal:3306 -L 2222:git.internal:22 user@bastion.example.com otworzy trzy tunele: do panelu administracyjnego (8080), bazy danych (3306) i serwera git (2222). Bardziej eleganckim rozwiązaniem jest zdefiniowanie tych tuneli w pliku ~/.ssh/config. Sekcja Host definiuje alias, a dyrektywy LocalForward określają tunele. Po zapisaniu wystarczy ssh bastion, a wszystkie tunele uruchomią się automatycznie. To szczególnie przydatne, gdy codziennie pracujesz z tym samym zestawem tuneli. Możesz również dodać flagi takie jak -N (nie uruchamiaj shella) i -f (praca w tle), aby tunel działał w tle bez interaktywnej sesji. W pliku config odpowiadają temu dyrektywy: "PermitLocalCommand yes" i "LocalCommand ssh -Nf -L ...". Uwaga: otwieranie wielu tuneli zwiększa zużycie pamięci na serwerze SSH (każdy tunel to osobny kanał w warstwie Connection), ale w praktyce jest to pomijalne.

Remote Forwarding (tunelowanie odwrotne) to mechanizm, który odwraca kierunek Local Forwarding. Zamiast otwierać port na kliencie i przekierowywać do serwera, otwieramy port na serwerze i przekierowujemy do klienta. Działa to tak: z maszyny A (np. laptop za NAT-em w sieci domowej) łączymy się z publicznym serwerem B, używając flagi -R. Na serwerze B zostaje otwarty port (np. 2222). Każdy, kto połączy się z serwerem B na port 2222, zostanie przekierowany przez tunel SSH z powrotem do maszyny A (laptopa) na wskazany port. To bardzo przydatne, gdy maszyna A jest za restrykcyjnym NAT-em lub firewallem i nie można nawiązać bezpośredniego połączenia przychodzącego. Otwierając tunel odwrotny z A do publicznego serwera B, umożliwiasz innym (lub sobie z innej lokalizacji) dostęp do usług działających na A. Klasyczny przykład: pracownik zdalny ma serwer deweloperski w domowej sieci za NAT-em; z domu łączy się z serwerem firmowym przez tunel odwrotny, a następnie z pracy może połączyć się z firmowym serwerem na porcie tunelu i trafić do domowego serwera. Uwaga: wymaga to ustawienia GatewayPorts yes w sshd_config na serwerze, jeśli chcemy nasłuchiwać na interfejsie innym niż loopback.

Omijanie NAT i firewalla za pomocą Remote Forwarding to jedna z najbardziej spektakularnych możliwości SSH. Wyobraź sobie, że jesteś w delegacji w sieci hotelowej, która blokuje wszystkie porty przychodzące (a często również wychodzące poza 80 i 443). Chcesz, aby twój kolega z biura mógł połączyć się z twoim laptopem przez SSH. Rozwiązanie: na laptopie (który ma dostęp do Internetu przez hotelowy NAT) wykonujesz: ssh -R 2222:127.0.0.1:22 user@vps.example.com. To polecenie otwiera na VPS-ie port 2222, który jest przekierowany do SSH na twoim laptopie. Teraz kolega w biurze wykonuje: ssh -p 2222 user@vps.example.com - i trafia na twojego laptopa. Wszystko działa, mimo że laptop jest za restrykcyjnym NAT-em. Kluczowa kwestia: jeśli chcemy, aby port na serwerze był dostępny z zewnątrz (a nie tylko z localhosta), na serwerze musi być ustawione GatewayPorts yes w sshd_config. Bez tego port 2222 będzie nasłuchiwał tylko na 127.0.0.1 na VPS-ie, co oznacza, że tylko z samego VPS-a można by się połączyć. Można też użyć ssh -R 0.0.0.0:2222:127.0.0.1:22, ale to wymaga wsparcia po stronie serwera.

W środowisku produkcyjnym Remote Forwarding znajduje zastosowanie wszędzie tam, gdzie urządzenie nie ma publicznego adresu IP, ale musi być dostępne zdalnie. Przykład: serwer w oddziale firmy, który nie ma publicznego IP, ale ma dostęp do Internetu przez NAT. Z tego serwera nawiązujemy połączenie SSH z centralnym serwerem zarządzania (public-server.com), otwierając tunel odwrotny dla SSH i panelu webowego. Od tej pory administratorzy mogą łączyć się z panelami urządzeń w oddziale bez VPN i bez konfiguracji przekierowania portów na lokalnym routerze. Problem: co jeśli tunel się zerwie (np. restart serwera, przerwa w dostępie do Internetu)? Rozwiązaniem jest autossh - niewielkie narzędzie, które uruchamia SSH w pętli: monitoruje połączenie (wysyłając dane keepalive) i automatycznie restartuje je po zerwaniu. Przykładowa komenda: autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -N -R 8080:127.0.0.1:80 user@public-server.com. Flaga -M 0 wyłącza wewnętrzny monitoring autossh na rzecz ServerAliveInterval. autossh można skonfigurować jako usługę systemd, aby uruchamiał się automatycznie przy starcie systemu.

Dynamic Forwarding to najbardziej elastyczna forma tunelowania SSH. Zamiast ręcznie określać, który port na kliencie ma być przekierowany do którego hosta i portu na serwerze, SSH tworzy serwer proxy SOCKS5 na wskazanym lokalnym porcie. Aplikacje obsługujące SOCKS5 (przeglądarki, klienty poczty, narzędzia sieciowe) mogą skonfigurować ten proxy - a cały ich ruch będzie przekierowany przez tunel SSH do serwera, a stamtąd do docelowego hosta. Decyzja o tym, dokąd ruch ma trafić, jest podejmowana dynamicznie przez aplikację kliencką. To niezwykle przydatne, gdy chcesz, aby cały ruch przeglądarki pochodził z IP serwera SSH (np. omijanie blokad geograficznych) lub gdy chcesz zabezpieczyć ruch w niezaufanej sieci Wi-Fi (hotel, kawiarnia). Aby skonfigurować przeglądarkę Firefox do użycia SOCKS5 proxy: Preferencje -> Ustawienia sieci -> Ręczna konfiguracja proxy -> SOCKS Host: 127.0.0.1, Port: 1080, SOCKS v5. Dodatkowo w about:config ustaw network.proxy.socks_remote_dns na true (DNS będzie rozwiązywany przez serwer, a nie lokalnie). Chrome używa flag --proxy-server="socks5://127.0.0.1:1080" --host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE localhost".

Po uruchomieniu SSH z flagą -D (ssh -D 1080 user@server) musisz skonfigurować aplikację do korzystania z proxy SOCKS5. Firefox ma wbudowaną natywną obsługę SOCKS5 z możliwością proxy DNS - to ważne, bo bez tego zapytania DNS byłyby rozwiązywane lokalnie (ujawniając twoje intencje lokalnemu dostawcy). Chrome nie ma w GUI opcji proxy SOCKS - trzeba użyć flag wiersza poleceń. Alternatywnie można użyć rozszerzenia Proxy SwitchyOmega dla Chrome, które umożliwia szybkie przełączanie między proxy. W systemach Unix/Linux można ustawić zmienną ALL_PROXY (lub http_proxy/https_proxy) dla aplikacji konsolowych: export ALL_PROXY=socks5://127.0.0.1:1080. Polecenia takie jak curl, wget, git (https) będą korzystać z proxy. Weryfikacja: curl ifconfig.me powinien zwrócić IP serwera SSH, a nie twoje lokalne IP. Uwaga: SOCKS5 proxy przez SSH nie szyfruje ruchu między serwerem SSH a docelowym serwerem WWW - jeśli potrzebujesz pełnego szyfrowania end-to-end, używaj HTTPS. Tunel SSH chroni tylko odcinek laptop -> serwer SSH. Po wyjściu z serwera SSH ruch idzie do Internetu "normalnie" - stąd konieczność HTTPS dla wrażliwych danych.

Wybór odpowiedniego typu tunelowania zależy od scenariusza. Local Forwarding (-L) jest najprostsze i najczęściej używane: wiesz, do jakiej usługi chcesz uzyskać dostęp (np. baza MySQL, panel webowy, RDP) i przez które porty. Remote Forwarding (-R) jest przydatne, gdy to ty jesteś za NAT-em i chcesz być dostępny z zewnątrz. Dynamic Forwarding (-D) jest najbardziej elastyczne - nie wymaga wcześniejszej wiedzy o docelowych portach, ale wymaga, aby aplikacja obsługiwała SOCKS5. Warto znać wszystkie trzy typy, ponieważ w realnej pracy administratora sieci spotkasz każdy z nich. Przykładowo: używasz -L do podłączenia się do bazy danych na produkcji, -R do utrzymania dostępu do serwera w oddziale za NAT-em, a -D do bezpiecznego przeglądania Internetu z hotelowej sieci Wi-Fi. Można również łączyć typy w jednym połączeniu: ssh -L 8080:web:80 -R 2222:localhost:22 -D 1080 user@server otworzy jednocześnie tunel lokalny, odwrotny i dynamiczny. Pamiętaj jednak, że każdy tunel zwiększa obciążenie serwera SSH i liczbę otwartych kanałów.

GatewayPorts to dyrektywa sshd_config, która kontroluje, na których interfejsach sieciowych mogą nasłuchiwać tunele SSH. Domyślnie (GatewayPorts no) tunele -R i -L nasłuchują tylko na 127.0.0.1 - są dostępne tylko z lokalnej maszyny. Gdy ustawisz GatewayPorts yes, serwer pozwala na wiązanie tuneli do 0.0.0.0 (wszystkie interfejsy), co oznacza, że inne maszyny w sieci mogą łączyć się z tunelem. To przydatne, gdy chcesz udostępnić tunel zespołowi: otwierasz tunel z serwera wewnętrznego do bastiona, a koledzy w biurze łączą się z bastionem na porcie tunelu. Ryzyko: jeśli nie kontrolujesz, kto ma dostęp do sieci serwera, tunel może zostać wykorzystany przez niepowołane osoby. Dlatego w środowisku produkcyjnym często stosuje się podejście warstwowe: tunel nasłuchuje na localhost, a dostęp do niego jest kontrolowany przez dodatkowy firewall lub drugi tunel z kolejnego serwera. Można również użyć ssh -R z adresem IP konkretnego interfejsu, np. ssh -R 10.0.0.1:2222:127.0.0.1:22 user@server, co ogranicza nasłuchiwanie do konkretnej podsieci.

Architektura z bastion host (inaczej jump server, SSH gateway) to standard w środowiskach produkcyjnych. Bastion to jedyny serwer w sieci, który ma publiczny adres IP i akceptuje połączenia SSH z zewnątrz. Wszystkie pozostałe serwery są dostępne tylko z sieci wewnętrznej - nie mają publicznych IP, a firewall blokuje do nich bezpośredni dostęp. Administrator łączy się najpierw z bastionem, a stamtąd do serwerów wewnętrznych. OpenSSH 7.3+ wprowadził wygodną flagę -J (ProxyJump), która automatyzuje ten proces. Flaga -J tworzy połączenie SSH do bastionu, a następnie przez niego tunel do serwera docelowego. Wszystko w jednym poleceniu. Można również tworzyć łańcuchy bastionów: ssh -J user@bastion1,user@bastion2 user@target. W pliku ~/.ssh/config można zdefiniować ProxyJump dla konkretnego hosta, co pozwala na przezroczyste łączenie: ssh target automatycznie użyje bastionu. ProxyJump jest bezpieczniejsze niż ProxyCommand, ponieważ nie wymaga uruchamiania drugiego procesu SSH i lepiej obsługuje forwarding kluczy (agent forwarding). Podczas tunelowania przez bastion, opcja -L na serwer docelowy tuneluje ruch przez oba serwery.

ssh-agent to proces uruchamiany na maszynie klienta, który przechowuje odblokowane klucze prywatne (po wpisaniu passphrase raz). Gdy łączysz się z serwerem przez SSH, agent automatycznie obsługuje uwierzytelnienie - nie musisz ponownie wpisywać hasła do klucza. Agent Forwarding idzie o krok dalej: gdy z serwera A łączysz się z serwerem B (np. z bastionu do serwera wewnętrznego), agent na twojej lokalnej maszynie jest "forwardowany" przez połączenie SSH, umożliwiając uwierzytelnienie na serwerze B bez przechowywania klucza prywatnego na serwerze A. To bardzo wygodne w architekturze z bastionem: klucz prywatny pozostaje tylko na twoim laptopie, nigdy nie jest kopiowany na bastion. Jednak Agent Forwarding niesie ryzyko: osoba z dostępem root na bastionie może podłączyć się do gniazda (socket) forwardowanego agenta i użyć go do logowania na serwery, do których masz dostęp. Dlatego w środowiskach o podwyższonych wymogach bezpieczeństwa stosuje się ograniczone certyfikaty SSH (SSH Certificates) zamiast Agent Forwarding. Jeśli musisz użyć -A, ogranicz zasięg używając ssh -o "ForwardAgent yes" tylko do zaufanych serwerów.

Plik ~/.ssh/config to jedno z najpotężniejszych narzędzi w arsenale administratora SSH. Pozwala na zdefiniowanie spersonalizowanych ustawień dla każdego serwera, z którym się łączysz - bez potrzeby pamiętania flag i parametrów. Każda sekcja zaczyna się od słowa kluczowego "Host", po którym następuje wzorzec (alias, adres IP lub wyrażenie z gwiazdką *). W sekcji definiujemy parametry: HostName (prawdziwy adres), User, Port, IdentityFile (ścieżka do klucza prywatnego), LocalForward (tunele), ProxyJump (bastion) i wiele innych. Sekcja "Host *" definiuje ustawienia domyślne dla wszystkich połączeń - tutaj warto umieścić opcje bezpieczeństwa: ForwardAgent no, Compression no, ServerAliveInterval 60. Plik może zawierać wiele sekcji, a SSH wybiera najbardziej specyficzną (najdłuższy wzorzec). Można również użyć Include ~/.ssh/config.d/* aby podzielić konfigurację na mniejsze pliki. Ważne: prawa dostępu do ~/.ssh/config powinny być 600 (tylko właściciel może czytać), ponieważ plik może zawierać wrażliwe informacje, takie jak nazwy serwerów czy wzorce połączeń.

SSH Certificates (certyfikaty SSH) to rozwiązanie problemu skalowalności zarządzania kluczami w dużych organizacjach. W tradycyjnym podejściu, gdy masz 100 serwerów i 10 administratorów, musisz dodać klucz publiczny każdego administratora do authorized_keys na każdym serwerze. Gdy administrator odchodzi, musisz usunąć jego klucz ze wszystkich serwerów. Przy certyfikatach: konfigurujesz na każdym serwerze klucz publiczny urzędu certyfikacji (CA) w dyrektywie TrustedUserCAKeys. Następnie każdy administrator generuje swoją parę kluczy, a CA (dedykowany serwer lub skrypt) podpisuje klucz publiczny, tworząc certyfikat z datą ważności (np. 1 rok). Administrator używa swojego klucza prywatnego + certyfikatu do logowania. Jeśli administrator odchodzi, po prostu nie przedłużasz certyfikatu - nie musisz modyfikować żadnego serwera. Certyfikaty mogą zawierać ograniczenia: nazwę użytkownika (principal), źródłowe IP, komendy, które można wykonać. To znacznie bezpieczniejsze i wygodniejsze niż ręczne zarządzanie authorized_keys. W praktyce certyfikaty SSH są standardem w firmach zatrudniających powyżej kilkudziesięciu administratorów.

Od Windows 10 wersji 1809 (2018) Microsoft dostarcza natywny port OpenSSH dla Windows - zarówno klient (ssh.exe), jak i serwer (sshd.exe). To koniec ery, w której administratorzy Windows musieli instalować Putty, Cygwin czy inne narzędzia stron trzecich. Serwer SSH na Windows instaluje się przez interfejs "Opcjonalne funkcje" lub przez PowerShell: Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0. Plik konfiguracyjny sshd_config znajduje się w C:\ProgramData\ssh\. Składnia jest identyczna jak w Linux, ale są pewne różnice: domyślnym shellem jest cmd.exe (można zmienić na PowerShell przez dyrektywę Subsystem), uwierzytelnianie może korzystać z NTLM lub Kerberos, a konta użytkowników to standardowe konta Windows. PermitRootLogin dotyczy konta Administrator. Klucze SSH dla Windows przechowywane są w %USERPROFILE%\.ssh\. Można również używać ssh-agent na Windows (usługa "OpenSSH Authentication Agent") do przechowywania odblokowanych kluczy. Dla starszych wersji Windows zaleca się instalację OpenSSH przez Chocolatey lub z oficjalnego repozytorium GitHub Microsoft.

Fail2Ban to podstawowe narzędzie do ochrony SSH przed atakami brute-force na poziomie firewalla. Działa na zasadzie monitorowania plików logów (auth.log, secure) i wyłapywania wzorców nieudanych logowań. Po przekroczeniu progu (domyślnie 5 prób, 10 minut) fail2ban tworzy regułę blokującą w iptables/nftables/firewalld. Konfiguracja dla SSH znajduje się w /etc/fail2ban/jail.d/sshd.local: [sshd] enabled = true, maxretry = 5, bantime = 10m, findtime = 10m. fail2ban jest skuteczny przeciwko atakom z pojedynczego źródła, ale nie chroni przed atakami rozproszonymi (botnety). Dodatkowo fail2ban zużywa zasoby (skanowanie logów, proces Python) - na małych serwerach może to być odczuwalne. sshguard to lżejsza alternatywa napisana w C, która robi to samo, ale z mniejszym narzutem. Oba narzędzia są przydatne, ale NIGDY nie powinny być jedyną linią obrony - podstawą jest prawidłowa konfiguracja sshd (wyłączenie haseł, klucze, AllowGroups). Fail2Ban to wisienka na torcie, a nie sam tort.

Tunelowanie SSH to jedna z tych umiejętności, które odróżniają początkującego administratora od doświadczonego inżyniera sieci. Pozwala na kreatywne rozwiązywanie problemów dostępu bez konieczności modyfikacji konfiguracji firewalla czy routera. W środowisku produkcyjnym tunele SSH są używane na co dzień: do awaryjnego dostępu do baz danych, do utrzymania łączności z serwerami w oddziałach (przez Remote Forwarding), do bezpiecznego przeglądania Internetu z niezaufanych sieci (Dynamic Forwarding) oraz do łączenia się z serwerami wewnętrznymi przez bastion host (ProxyJump). Kluczowe zasady: (1) używaj -N i -f dla tuneli działających w tle, (2) definiuj tunele w ~/.ssh/config zamiast wpisywać za każdym razem długie polecenia, (3) kontroluj dostęp do tuneli przez GatewayPorts i firewalle, (4) używaj autossh do utrzymania trwałych tuneli. Pamiętaj, że tunel SSH nie szyfruje ruchu end-to-end (tylko od klienta do serwera SSH) - dla pełnego szyfrowania używaj HTTPS, TLS lub VPN w połączeniu z SSH.

Rozpoczynamy laboratorium praktyczne. Pierwszym krokiem jest wygenerowanie pary kluczy na komputerze, z którego będziesz się łączyć z serwerami (maszyna kliencka). Na Linux/macOS otwórz terminal; na Windows użyj PowerShell (natywny OpenSSH) lub WSL. Komenda ssh-keygen -t ed25519 -a 100 -C "twoj@email.com" generuje: (a) klucz prywatny ~/.ssh/id_ed25519 - NIGDY nie udostępniaj, (b) klucz publiczny ~/.ssh/id_ed25519.pub - możesz kopiować na serwery. Flaga -a 100 określa liczbę rund funkcji KDF (Key Derivation Function), która chroni klucz prywatny przed atakiem brute-force, jeśli plik klucza wpadnie w niepowołane ręce. Domyślnie -a wynosi 16 (dla Ed25519), ale 100 rund zwiększa bezpieczeństwo bez odczuwalnego spowolnienia przy logowaniu. Passphrase to hasło, które chroni klucz prywatny. Bez passphrase, jeśli ktoś zdobędzie twój plik klucza prywatnego, może natychmiast logować się na wszystkie serwery. Z passphrase, atakujący musi najpierw złamać hasło - co przy -a 100 jest bardzo czasochłonne. Używaj ssh-agent do przechowywania odblokowanego klucza w pamięci: ssh-add ~/.ssh/id_ed25519 (poprosi o passphrase raz, potem pamięta aż do wylogowania).

ssh-copy-id to narzędzie, które automatyzuje proces dodawania klucza publicznego do pliku authorized_keys na serwerze. Działa to w trzech krokach: (1) łączy się z serwerem przez SSH (używając hasła, jeśli to jeszcze skonfigurowane), (2) tworzy katalog ~/.ssh na serwerze, jeśli nie istnieje, (3) dodaje twój klucz publiczny do pliku ~/.ssh/authorized_keys i ustawia odpowiednie prawa (600 dla pliku, 700 dla katalogu). Jeśli twój system nie ma ssh-copy-id, możesz zrobić to ręcznie: cat klucz.pub | ssh user@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys && chmod 700 ~/.ssh". Po dodaniu klucza przetestuj logowanie: ssh user@server. Jeśli wszystko działa, możesz od razu przejść do hardeningu - wyłączenia logowania hasłem. Jeśli logowanie nie działa, sprawdź: (a) prawa dostępu do ~/.ssh i authorized_keys na serwerze, (b) czy w sshd_config jest włączone PubkeyAuthentication yes, (c) logi na serwerze: tail /var/log/auth.log (Linux) lub C:\ProgramData\ssh\logs\ (Windows). Częsty błąd: złe prawa - authorized_keys musi mieć 600, .ssh 700.

ssh-agent to demon uruchamiany w tle, który przechowuje odblokowane klucze prywatne w pamięci operacyjnej. Dzięki niemu wpisujesz passphrase tylko raz podczas dodawania klucza do agenta, a wszystkie późniejsze połączenia SSH używają go automatycznie. W systemach Linux/macOS agent uruchamiany jest przez eval $(ssh-agent) w sesji terminala. W Windows od Windows 10 istnieje usługa "OpenSSH Authentication Agent", którą można włączyć i ustawić na automatyczne uruchamianie. Klucze są dodawane do agenta komendą ssh-add. Aby sprawdzić, jakie klucze są aktualnie w agencie, użyj ssh-add -l (wyświetli odciski palców) lub ssh-add -L (wyświetli pełne klucze publiczne). ssh-agent wspiera również Agent Forwarding (-A), który pozwala używać lokalnego agenta podczas łączenia się przez pośrednie serwery. Pamiętaj o zabezpieczeniu: jeśli zostawisz komputer bez nadzoru, każdy może użyć twojego agenta do logowania się na serwery. Dlatego niektóre środowiska używają narzędzi takich jak Keychain (macOS) lub seahorse (GNOME) z dodatkowymi zabezpieczeniami.

Plik ~/.ssh/config to jedno z najpotężniejszych narzędzi w codziennej pracy administratora. Zamiast wpisywać za każdym razem ssh -p 51022 -i ~/.ssh/id_ed25519 -L 3306:127.0.0.1:3306 admin@192.168.1.100, definiujesz alias "serwer-prod" w pliku config i łączysz się komendą ssh serwer-prod. Plik może zawierać wiele sekcji Host, a nawet wzorce (Host *.example.com). Można również zdefiniować ustawienia domyślne w sekcji Host *, które będą stosowane do wszystkich połączeń: ForwardAgent no, ServerAliveInterval 60, Compression no. Ważne: plik config musi mieć prawa dostępu 600 (tylko właściciel może czytać i zapisywać), ponieważ może zawierać poufne informacje, takie jak adresy serwerów, nazwy użytkowników i konfiguracje tuneli. SSH zignoruje plik config, jeśli jego prawa będą zbyt otwarte. W systemach enterprise często zarządza się plikami konfiguracyjnymi przez narzędzia do zarządzania konfiguracją (Ansible, Puppet), co zapewnia spójność między zespołami.

Tryb verbose (-v) to podstawowe narzędzie diagnostyczne SSH. Po uruchomieniu ssh -v user@server SSH wypisze szczegółowy log procesu łączenia. Na początku zobaczysz wersję OpenSSH i linię "debug1: Reading configuration data", która informuje, które pliki konfiguracyjne zostały odczytane. Następnie SSH wyświetla informacje o negocjacji kluczy (kex), w tym listę akceptowanych algorytmów. To bardzo przydatne, gdy serwer nie akceptuje twojego klucza - zobaczysz, które metody uwierzytelniania są dostępne: "debug1: Authentications that can continue: publickey,password". Jeśli widzisz tylko "publickey", to znaczy, że hasła są już wyłączone. SSH pokaże również, które klucze próbuje: "debug1: Offering public key: /home/user/.ssh/id_ed25519". Jeśli serwer odrzuci klucz, zobaczysz "debug1: Authentications that can continue: publickey". Linia "Authentication succeeded" oznacza sukces. Dla jeszcze głębszej diagnostyki użyj -vvv, który pokaże dane surowe protokołu - przydatne przy debugowaniu nietypowych problemów sieciowych.

Ostatnim krokiem laboratorium jest uruchomienie tunelu Local Forwarding i weryfikacja jego działania. Uruchamiamy SSH z flagami -L (przekierowanie portu), -N (bez otwierania sesji shell) i -f (praca w tle). Komenda: ssh -L 13306:127.0.0.1:3306 -Nf user@server. Teraz na lokalnym porcie 13306 nasłuchuje SSH. Każde połączenie z localhost:13306 jest przekazywane przez szyfrowany tunel do serwera, a następnie na 127.0.0.1:3306 (czyli do MySQL na serwerze). Aby zweryfikować: uruchom klienta MySQL: mysql -h 127.0.0.1 -P 13306 -u root -p. Jeśli widzisz zachętę MySQL, tunel działa poprawnie. Sprawdź netstat, aby upewnić się, że proces SSH nasłuchuje na porcie 13306. Aby zatrzymać tunel, znajdź PID procesu SSH (ps aux | grep ssh) i zakończ go (kill PID). Możesz również użyć pkill -f "ssh -L" aby zabić wszystkie procesy SSH z flagą -L. W środowisku produkcyjnym tunele są zwykle definiowane w ~/.ssh/config z opcjami LocalForward, co eliminuje potrzebę ręcznego wpisywania flag.

Problemy z prawami dostępu (permissions) to najczęstsza przyczyna problemów z SSH, zwłaszcza u początkujących administratorów. SSH ma bardzo restrykcyjną politykę dotyczącą praw dostępu do plików konfiguracyjnych i kluczy. Jeśli klucz prywatny ma zbyt otwarte prawa (np. 644), SSH odmówi użycia go z komunikatem "Permissions are too open". To zabezpieczenie przed sytuacją, w której inny użytkownik systemu mógłby odczytać twój klucz prywatny. Rozwiązaniem jest ustawienie praw 600 dla klucza prywatnego (tylko właściciel może czytać i zapisywać). Na serwerze plik authorized_keys również musi mieć 600, a katalog .ssh 700. Jeśli te prawa są nieprawidłowe, SSH zignoruje authorized_keys i uwierzytelnienie kluczem nie będzie możliwe. Warto pamiętać również o prawach do pliku known_hosts (644) i config (600). Komenda sprawdzająca prawa: ls -la ~/.ssh/. Po ustawieniu prawssh powinien działać poprawnie. W razie wątpliwości sprawdź logi serwera: tail -f /var/log/auth.log (Linux) lub C:\ProgramData\ssh\logs\ (Windows).

Ostrzeżenie o zmianie klucza hosta to jeden z najbardziej niepokojących komunikatów SSH. Pojawia się, gdy klucz publiczny serwera różni się od zapisanego w pliku known_hosts na kliencie. Może to oznaczać: (a) serwer został reinstalowany i wygenerował nowy klucz hosta, (b) serwer został podmieniony na inną maszynę, (c) ktoś próbuje przeprowadzić atak Man-in-the-Middle (MITM). W przypadku (a) i (b) rozwiązaniem jest usunięcie starego wpisu z known_hosts komendą ssh-keygen -R server.example.com. W przypadku (c) - przerwij połączenie i zweryfikuj autentyczność serwera. Atak MITM w SSH polega na tym, że atakujący przechwytuje połączenie i podszywa się pod serwer, a klient bez ostrzeżenia akceptuje nowy, nieznany klucz (przy pierwszym połączeniu). Dlatego zawsze weryfikuj odcisk klucza serwera przy pierwszym połączeniu. Odcisk można sprawdzić na serwerze komendą: ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub. Bezpiecznym podejściem jest publikowanie odcisków kluczy w centralnym miejscu (np. wiki firmowe, system CMDB) lub użycie SSHFP records w DNS do automatycznej weryfikacji.

Każdy z tych błędów ma swoje charakterystyczne przyczyny i rozwiązania. "Connection refused" oznacza, że połączenie TCP zostało odrzucone - serwer nie nasłuchuje na danym porcie. Sprawdź: netstat -tlnp | grep :22 (czy sshd słucha), systemctl status sshd (czy usługa jest uruchomiona), firewall-cmd --list-all (Czy firewall nie blokuje). "Could not resolve hostname" oznacza problem z DNS - sprawdź ping nazwa-serwera i /etc/resolv.conf. "Permission denied" z listą metod (publickey, gssapi) oznacza, że żadna z próbowanych metod nie zadziałała. Najczęstsze przyczyny: (1) zły klucz - nie ten plik lub nie ten typ, (2) złe prawa do plików, (3) klucz publiczny nie ma w authorized_keys, (4) klient nie mógł przeczytać klucza prywatnego (złe prawa). W takich przypadkach uruchom ssh -vvv, aby zobaczyć, które klucze są próbowane i jaka jest dokładna przyczyna odrzucenia. Logi serwera w /var/log/auth.log (lub /var/log/secure na RHEL/CentOS) również zawierają szczegółowe informacje o nieudanych próbach logowania, w tym konkretną przyczynę odrzucenia klucza.

Cheat Sheet powyżej zawiera dziesięć najważniejszych komend SSH, które powinien znać każdy administrator sieci. Warto wydrukować tę listę i mieć ją pod ręką podczas codziennej pracy. Generowanie kluczy Ed25519 z opcją -a 100 zapewnia wysoki poziom bezpieczeństwa bez utraty wydajności. Kopiowanie klucza przez ssh-copy-id automatyzuje proces konfiguracji authorized_keys. Logowanie z jawnym wskazaniem klucza i portu (-i i -p) jest przydatne przy serwerach z niestandardową konfiguracją. Tunele lokalne, odwrotne i SOCKS5 to trzy podstawowe typy tunelowania SSH - znajomość ich składni pozwala szybko otworzyć dostęp do potrzebnych usług. Skok przez bastion z flagą -J (ProxyJump) to standard w nowoczesnych architekturach sieciowych. Debugowanie z -vvv to pierwszy krok w rozwiązywaniu problemów z połączeniami. Usuwanie klucza hosta komendą ssh-keygen -R jest bezpieczne i nie wymaga ręcznej edycji pliku known_hosts. Na koniec: zawsze testuj konfigurację sshd komendą sshd -t przed restartem demona - to może uratować cię przed utratą dostępu do serwera.

Niniejsza prezentacja (szósta z cyklu Administracja Sieci Komputerowych) objęła szeroki zakres tematów związanych z protokołem SSH. Od historycznej ewolucji zdalnego logowania (Telnet, rlogin, SSH-1, SSH-2), przez szczegółową mechanikę kryptograficzną (szyfrowanie symetryczne i asymetryczne, Diffie-Hellman, ECDH), aż po praktyczny hardening serwera i klienta oraz zaawansowane techniki tunelowania. W laboratorium każdy uczestnik mógł samodzielnie wygenerować parę kluczy Ed25519, skopiować ją na serwer, skonfigurować klienta z plikiem config, debugować połączenie z flagą -v oraz uruchomić tunel Local Forwarding. Pamiętaj, że bezpieczeństwo to proces, a nie stan - regularnie przeglądaj konfigurację SSH, aktualizuj oprogramowanie i monitoruj logi. W razie problemów: sprawdź prawa dostępu do plików, użyj trybu verbose i analizuj logi serwera. Życzę powodzenia w administracji sieci!