Home 1: Adresacja 2: DHCP 3: DNS 4: WWW 5: Proxy 6: SSH 7: Monitoring 8: Logowanie 9: Fileserv 10: Ansible 11: FW + NAT 12: Wirtualizacja
1/49
SSH – bezpieczeństwo na warstwie administracyjnej
Cel slajdu: Slajd omawia zagadnienie „SSH – bezpieczeństwo na warstwie administracyjnej” w kontekście: Bezpieczny zdalny dostęp do infrastruktury sieciowej.

Bezpieczny zdalny dostęp do infrastruktury sieciowej

  • Protokół Secure Shell (SSH) stanowi fundamentalny standard branżowy bezpiecznego zarządzania węzłami sieciowymi i serwerami w architekturze TCP/IP.
  • Standard IETF SSH-2, skodyfikowany w dokumentach RFC 4251, RFC 4252, RFC 4253 oraz RFC 4254, zastąpił podatne na ataki historyczne rozwiązania pierwszej generacji.
  • Ochrona płaszczyzny zarządzania (Management Plane) wymaga zagwarantowania czterech krytycznych atrybutów bezpieczeństwa teleinformatycznego:
    • Poufności (Confidentiality): silne szyfrowanie symetryczne strumienia danych uniemożliwiające podsłuch;
    • Integralności (Integrity): kryptograficzne kody uwierzytelniania wiadomości (MAC/AEAD) wykrywające modyfikację pakietów;
    • Uwierzytelniania stron (Authentication): asymetryczna weryfikacja tożsamości stacji klienckiej oraz hosta serwera;
    • Niezaprzeczalność i rozliczalność: ścisłe powiązanie sesji z uprawnionym administratorem oraz audytowalność zdarzeń.
  • Niniejszy wykład przedstawia mechanikę kryptograficzną, wzorcową konfigurację obronną (hardening), tunelowanie usług oraz procedury diagnostyczne.
SSH – bezpieczeństwo na warstwie administracyjnej: Slajd przedstawia zagadnienie Bezpieczny zdalny dostęp do infrastruktury sieciowej w ramach tematu SSH – bezpieczeństwo na warstwie administracyjnej na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
SSH - bezpieczeństwo administracyjne
2/49
Cel warsztatu
Cel slajdu: Slajd określa wymagane efekty uczenia się, czyli wiedzę i umiejętności, które uczestnik opanuje po zajęciach i laboratorium.

Praktyczne cele warsztatu SSH

  • Zrozumienie mechanizmów kryptograficznych leżących u podstaw protokołu SSH-2: protokołów uzgadniania kluczy (Diffie-Hellman, ECDH), szyfrów symetrycznych (AES-GCM, ChaCha20-Poly1305) oraz podpisów cyfrowych (Ed25519, RSA).
  • Opanowanie procedur generowania i zarządzania kluczami asymetrycznymi: bezpieczne stosowanie narzędzia ssh-keygen, ochrona klucza prywatnego frazą szyfrującą (passphrase) oraz automatyzacja pracy z demonem ssh-agent.
  • Implementacja produkcyjnego hardeningu serwera: eliminacja wektorów ataków brute-force w pliku /etc/ssh/sshd_config, bezwzględne wyłączenie logowania hasłem, restrykcje konta root oraz autoryzacja grupowa.
  • Architektura zaawansowanego tunelowania ruchu:
    • Przekierowanie lokalne (Local Port Forwarding -L) na potrzeby bezpiecznego dostępu do izolowanych baz danych;
    • Przekierowanie zdalne (Remote Port Forwarding -R) do udostępniania usług zza translacji adresów NAT;
    • Dynamiczne proxy SOCKS5 (-D) oraz tranzyt przez serwery przesiadkowe (Bastion / Jump Host -J).
  • Metodyka diagnostyki inżynierskiej (Troubleshooting): analiza błędów uprawnień POSIX, rozwiązywanie konfliktów bazy known_hosts oraz zaawansowane debugowanie z flagami poziomu gadatliwości.
Cel warsztatu: Slajd przedstawia zagadnienie Praktyczne cele warsztatu SSH w ramach tematu Cel warsztatu na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Cel warsztatu
3/49
Agenda spotkania
Cel slajdu: Slajd przedstawia kolejność omawianych zagadnień i wskazuje miejsce bieżącego tematu w strukturze wykładu.

Plan warsztatu SSH

  • Blok I: Architektura i kryptografia protokołu SSH (slajdy 4–12)
    • Geneza i wady Telnetu oraz komend rodziny r (rlogin, rsh, rcp); specyfikacja standardu SSH-2;
    • Model trójwarstwowy (Transport, Authentication, Connection Layer);
    • Kryptografia symetryczna vs asymetryczna; protokoły Diffiego-Hellmana i ECDH;
    • Algorytmy kluczy (RSA, ECDSA, Ed25519) oraz weryfikacja tożsamości hosta.
  • Blok II: Produkcyjny hardening demona OpenSSH (slajdy 13–20)
    • Struktura pliku konfiguracyjnego sshd_config i testowanie składni;
    • Wymuszenie kluczy kryptograficznych i wyłączenie uwierzytelniania hasłem;
    • Blokada konta root, listy kontroli dostępu AllowGroups, ograniczenia sesji.
  • Blok III: Tunelowanie, zaawansowane routingi i infrastruktura (slajdy 21–38)
    • Przekierowania Local (-L), Remote (-R) i Dynamiczne (-D SOCKS5);
    • Bramy przesiadkowe (Bastion/Jump Host -J), ryzyka Agent Forwarding;
    • Konfiguracja ~/.ssh/config, certyfikaty SSH CA, integracja z Fail2Ban.
  • Blok IV: Laboratorium wdrożeniowe, diagnostyka i podsumowanie (slajdy 39–49)
    • Generowanie kluczy Ed25519, dystrybucja kluczy, konfiguracja agenta;
    • Analiza handshake z flagami -v/-vvv, prawa dostępu POSIX i ściągawka komend.
Agenda spotkania: Slajd przedstawia zagadnienie Plan warsztatu SSH w ramach tematu Agenda spotkania na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Agenda spotkania
4/49
Ewolucja zdalnego logowania
Cel slajdu: Slajd omawia zagadnienie „Ewolucja zdalnego logowania” w kontekście: Historia protokołów zdalnego dostępu.

Historia protokołów zdalnego dostępu

  • Protokół Telnet (RFC 854, 1983):
    • Przesyłał całą sesję terminalową (w tym identyfikatory i hasła użytkowników) w postaci jawnego tekstu (ang. cleartext);
    • Całkowity brak kryptograficznej ochrony przed podsłuchem pakietów (sniffing), manipulacją danymi i wstrzykiwaniem poleceń w locie (man-in-the-middle).
  • Zestaw narzędzi BSD r-commands (RFC 1282, 1985):
    • Programy rlogin, rsh, rcp oparte na zaufaniu do adresu IP i nazwy stacji (pliki /etc/hosts.equiv oraz ~/.rhosts);
    • Brak szyfrowania; podatność na podszywanie się pod adresy IP (IP spoofing) oraz zatruwanie bufora DNS (DNS spoofing).
  • Przełom – powstanie SSH-1 (1995):
    • Opracowany przez Tatu Ylönena po wykryciu masowego podsłuchu haseł na Uniwersytecie Technologicznym w Helsinkach;
    • Wprowadził szyfrowanie sesji, lecz cierpiał na wady projektowe (atak CRC-32 compensation attack, podatność na wstrzykiwanie kluczy serwera).
  • Standard współczesny – IETF SSH-2 (RFC 4251, 2006):
    • Całkowicie nowa architektura protokołu, brak wstecznej kompatybilności z SSH-1;
    • Modułowość, bezpieczna wymiana kluczy Diffie-Hellman/ECDH, kody MAC oraz zaawansowane multipleksowanie kanałów.
Ewolucja zdalnego logowania: Slajd przedstawia zagadnienie Historia protokołów zdalnego dostępu w ramach tematu Ewolucja zdalnego logowania na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Ewolucja zdalnego logowania
5/49
Architektura protokołu SSH-2
Cel slajdu: Slajd omawia zagadnienie „Architektura protokołu SSH-2” w kontekście: Budowa i warstwy SSH-2.

Budowa i warstwy SSH-2

  • Standard RFC 4251 definiuje modularną architekturę SSH-2 podzieloną na trzy niezależne warstwy funkcjonalne:
  • 1. Warstwa transportowa (Transport Layer Protocol – RFC 4253):
    • Odpowiada za zestawienie bezpiecznego, poufnego i integralnego kanału komunikacji nad protokołem TCP (standardowy port 22);
    • Realizuje negocjację algorytmów (pakiet SSH_MSG_KEXINIT), asymetryczną wymianę klucza sesji (Diffie-Hellman/ECDH), weryfikację klucza hosta serwera oraz inicjalizację szyfrów symetrycznych i kodów MAC.
  • 2. Warstwa uwierzytelniania użytkownika (User Authentication Layer – RFC 4252):
    • Działa wewnątrz zestawionego, zaszyfrowanego tunelu transportowego;
    • Weryfikuje tożsamość klienta za pomocą metod: publickey (podpis cyfrowy), password (hasło), keyboard-interactive (np. 2FA/PAM) lub gssapi-with-mic (Kerberos).
  • 3. Warstwa połączenia (Connection Layer Protocol – RFC 4254):
    • Zapewnia multipleksowanie wielu niezależnych kanałów logicznych w pojedynczym strumieniu kryptograficznym;
    • Obsługuje interaktywny terminal (shell), zdalne polecenia (exec), podsystemy transferu plików (SFTP), przekierowania portów (port forwarding) oraz sesje X11.
Architektura protokołu SSH-2: Slajd przedstawia zagadnienie Budowa i warstwy SSH-2 w ramach tematu Architektura protokołu SSH-2 na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Architektura protokołu SSH-2
6/49
Szyfrowanie symetryczne i asymetryczne w SSH
Cel slajdu: Slajd omawia zagadnienie „Szyfrowanie symetryczne i asymetryczne w SSH” w kontekście: Dwa rodzaje szyfrowania w SSH.

Dwa rodzaje szyfrowania w SSH

  • Szyfrowanie symetryczne (szyfrowanie danych sesji):
    • Ten sam klucz kryptograficzny służy zarówno do szyfrowania, jak i deszyfrowania strumienia informacji;
    • Charakteryzuje się ogromną wydajnością obliczeniową i niskim narzutem na procesor (wykorzystanie instrukcji AES-NI);
    • Stosowane algorytmy: ChaCha20-Poly1305 (algorytm strumieniowy AEAD) oraz AES-256-GCM / AES-128-CTR;
    • Służy do zabezpieczenia 100% przesyłanych danych po pomyślnym uzgodnieniu sesji.
  • Szyfrowanie asymetryczne (zarządzanie tożsamością i kluczami):
    • Wykorzystuje matematycznie powiązaną parę kluczy: klucz publiczny (jawny) oraz klucz prywatny (ściśle tajny);
    • Wysoki koszt obliczeniowy operacji na krzywych eliptycznych lub potęgach modularnych;
    • Zastosowanie w SSH: uwierzytelnianie tożsamości serwera (Host Key), uwierzytelnianie użytkownika (Public Key Authentication) oraz bezpieczne uzgodnienie klucza symetrycznego.
  • Model hybrydowy: SSH łączy wygodę i siłę asymetrii (do wymiany kluczy i podpisów) z szybkością szyfrów symetrycznych (do transmisji danych).
Szyfrowanie symetryczne i asymetryczne w SSH: Slajd przedstawia zagadnienie Dwa rodzaje szyfrowania w SSH w ramach tematu Szyfrowanie symetryczne i asymetryczne w SSH na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Szyfrowanie symetryczne i asymetryczne w SSH
7/49
Protokół Diffiego-Hellmana w SSH
Cel slajdu: Slajd omawia zagadnienie „Protokół Diffiego-Hellmana w SSH” w kontekście: Bezpieczna wymiana kluczy DH i ECDH.

Bezpieczna wymiana kluczy DH i ECDH

  • Protokół Diffiego-Hellmana (Whitfield Diffie, Martin Hellman, 1976):
    • Pozwala dwóm stronom komunikacji uzgodnić wspólny sekret kryptograficzny przez całkowicie jawny, podsłuchiwany kanał transmisyjny;
    • Bezpieczeństwo klasycznego DH opiera się na trudności rozwiązania problemu logarytmu dyskretnego w ciałach skończonych (MODP);
    • Nawet pełne przechwycenie wszystkich pakietów negocjacyjnych przez atakującego nie pozwala na odtworzenie klucza sesji.
  • ECDH (Elliptic Curve Diffie-Hellman):
    • Nowoczesna adaptacja wykorzystująca algebrę krzywych eliptycznych (ECDLP – Elliptic Curve Discrete Logarithm Problem);
    • Algorytm curve25519-sha256 (RFC 8731) stanowi domyślny standard w OpenSSH: wyższa szybkość obliczeń i mniejszy rozmiar parametrów przy maksymalnym poziomie bezpieczeństwa.
  • Własność utajniania z wyprzedzeniem (PFS – Perfect Forward Secrecy):
    • Klucze sesyjne są efemeryczne (jednorazowe) – po zakończeniu sesji są bezpowrotnie niszczone w pamięci RAM;
    • Ewentualna kompromitacja klucza prywatnego serwera w przyszłości nie umożliwia odszyfrowania historycznego ruchu zarejestrowanego przez podsłuchującego.
Protokół Diffiego-Hellmana w SSH: Slajd przedstawia zagadnienie Bezpieczna wymiana kluczy DH i ECDH w ramach tematu Protokół Diffiego-Hellmana w SSH na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Protokół Diffiego-Hellmana w SSH
8/49
Para kluczy: prywatny i publiczny
Cel slajdu: Slajd omawia zagadnienie „Para kluczy: prywatny i publiczny” w kontekście: Klucz prywatny i publiczny SSH.

Klucz prywatny i publiczny SSH

  • Klucz prywatny (Private Key):
    • Ściśle tajny, przechowywany wyłącznie na stacji roboczej klienta;
    • Nigdy pod żadnym pozorem nie może być przesyłany przez sieć ani udostępniany osobom trzecim;
    • Musi być chroniony silną frazą szyfrującą (passphrase) oraz restrykcyjnymi uprawnieniami systemu plików (chmod 600 ~/.ssh/id_ed25519).
  • Klucz publiczny (Public Key):
    • Kryptograficznie wyprowadzony z klucza prywatnego, jawny i bezpieczny w dystrybucji;
    • Instalowany na serwerach docelowych w pliku autoryzacyjnym użytkownika: ~/.ssh/authorized_keys (uprawnienia chmod 600).
  • Mechanizm uwierzytelniania wyzwanie-odpowiedź (Challenge-Response):
    • 1. Klient zgłasza chęć logowania i wskazuje swój klucz publiczny;
    • 2. Serwer sprawdza obecność klucza w authorized_keys i generuje unikalne, losowe wyzwanie;
    • 3. Klient podpisuje wyzwanie swoim kluczem prywatnym i odsyła podpis kryptograficzny;
    • 4. Serwer weryfikuje poprawność podpisu za pomocą znanego klucza publicznego. Hasło użytkownika nie istnieje i nie krąży w sieci.
Para kluczy: prywatny i publiczny: Slajd przedstawia zagadnienie Klucz prywatny i publiczny SSH w ramach tematu Para kluczy: prywatny i publiczny na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Para kluczy: prywatny i publiczny
9/49
Algorytmy kluczy: RSA, ECDSA, Ed25519
Cel slajdu: Slajd omawia zagadnienie „Algorytmy kluczy: RSA, ECDSA, Ed25519” w kontekście: RSA, ECDSA, Ed25519 w SSH.

RSA, ECDSA, Ed25519 w SSH

  • RSA (Rivest-Shamir-Adleman):
    • Najstarszy algorytm asymetryczny, oparty na trudności faktoryzacji dużych liczb złożonych;
    • Współcześnie klucze 2048-bitowe uznaje się za graniczne; zalecana długość to 3072 lub 4096 bitów;
    • OpenSSH od wersji 8.8 (2021) domyślnie wyłącza przestarzały algorytm podpisu ssh-rsa bazujący na podatnej funkcji skrótu SHA-1 (zastąpiony przez standard RFC 8332: rsa-sha2-256 i rsa-sha2-512).
  • ECDSA (Elliptic Curve Digital Signature Algorithm – RFC 5656):
    • Oparty na krzywych eliptycznych NIST (krzywe P-256, P-384, P-521);
    • Bardzo zwięzłe klucze i szybka weryfikacja; krytykowany za katastrofalną podatność na defekty generatora liczb losowych (powtórzenie wartości k-nonce prowadzi do natychmiastowego ujawnienia klucza prywatnego).
  • Ed25519 (Edwards-curve Digital Signature Algorithm – RFC 8709):
    • Oparty na krzywej Twisted Edwards (Curve25519) autorstwa Daniela J. Bernsteina;
    • Zapewnia stały czas wykonania operacji (odporność na ataki czasowe side-channel) oraz deterministyczny podpis;
    • Rekomendacja branżowa: klucz pierwszego wyboru we wszystkich nowoczesnych wdrożeniach (ssh-keygen -t ed25519).
Algorytmy kluczy: RSA, ECDSA, Ed25519: Slajd przedstawia zagadnienie RSA, ECDSA, Ed25519 w SSH w ramach tematu Algorytmy kluczy: RSA, ECDSA, Ed25519 na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Algorytmy kluczy: RSA, ECDSA, Ed25519
10/49
Klucz hosta – odcisk palca serwera
Cel slajdu: Slajd omawia zagadnienie „Klucz hosta – odcisk palca serwera” w kontekście: Weryfikacja tożsamości serwera SSH.

Weryfikacja tożsamości serwera SSH

  • Klucz hosta (Host Key):
    • Unikalna para kluczy generowana automatycznie podczas inicjalizacji demona SSH na serwerze (katalog /etc/ssh/ssh_host_*_key);
    • Służy do jednoznacznego potwierdzenia tożsamości serwera przed łączącym się klientem i zapobiegania atakom podszywania się (Man-in-the-Middle).
  • Zasada pierwszego zaufania (TOFU – Trust On First Use):
    • Podczas pierwszego połączenia klient otrzymuje skrót klucza publicznego serwera (fingerprint) i zostaje poproszony o manualną akceptację;
    • Po zatwierdzeniu publiczny klucz serwera zostaje trwale zapisany w lokalnej bazie klienta: ~/.ssh/known_hosts.
  • Procedura inżynierskiej weryfikacji odcisku palca (Fingerprint):
    • Wyświetlenie odcisku na serwerze: ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub;
    • Klient weryfikuje sumę kontrolną SHA256 wyświetloną na ekranie terminala z wartością uzyskaną z zaufanego kanału pozapasmowego (Out-of-Band).
  • Automatyzacja w skali enterprise: publikacja rekordów SSHFP (RFC 4255) w bezpiecznym DNS z rozszerzeniem DNSSEC lub wdrożenie Certyfikatów Hostów SSH.
Klucz hosta – odcisk palca serwera: Slajd przedstawia zagadnienie Weryfikacja tożsamości serwera SSH w ramach tematu Klucz hosta – odcisk palca serwera na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Host key - odcisk palca serwera
11/49
known_hosts i authorized_keys
Cel slajdu: Slajd omawia zagadnienie „known_hosts i authorized_keys” w kontekście: Zaufane hosty i autoryzowane klucze.

Zaufane hosty i autoryzowane klucze

  • W architekturze OpenSSH dwa pliki definiują zaufanie kryptograficzne w relacji klient-serwer:
  • 1. Plik klienta – ~/.ssh/known_hosts (Weryfikacja serwera):
    • Przechowuje odciski kluczy publicznych serwerów, z którymi stacja kliencka nawiązywała połączenia;
    • Chroni klienta przed podszywaniem się pod serwer przez atakującego (MITM);
    • Opcja HashKnownHosts yes haszuje nazwy i adresy IP serwerów, uniemożliwiając ich odczytanie w razie kradzieży stacji.
  • 2. Plik serwera – ~/.ssh/authorized_keys (Weryfikacja użytkownika):
    • Znajduje się w katalogu domowym konta na serwerze i zawiera listę kluczy publicznych uprawnionych do logowania;
    • Umożliwia nałożenie zaawansowanych restrykcji na pojedynczy klucz (ang. key options):
      • from="192.0.2.0/24" – logowanie dozwolone wyłącznie ze wskazanego podzbioru adresów IP;
      • command="/usr/local/bin/backup.sh" – wymuszenie uruchomienia wyłącznie jednego skryptu;
      • no-port-forwarding,no-X11-forwarding,no-pty – całkowita blokada tunelowania i interaktywnego shella.
known_hosts i authorized_keys: Slajd przedstawia zagadnienie Zaufane hosty i autoryzowane klucze w ramach tematu known_hosts i authorized_keys na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
known_hosts i authorized_keys
12/49
Odejście od RSA na rzecz Ed25519
Cel slajdu: Slajd omawia zagadnienie „Odejście od RSA na rzecz Ed25519” w kontekście: Nowoczesne algorytmy kluczy w standardzie OpenSSH.

Nowoczesne algorytmy kluczy w standardzie OpenSSH

  • Zmierzch algorytmu RSA:
    • Klucze RSA o długości poniżej 2048 bitów uznaje się za niebezpieczne i wycofane z użycia, a wariant 2048-bitowy zapewnia bezpieczeństwo jedynie krótkoterminowe (zaleca się 3072 lub 4096 bitów);
    • Projekt OpenSSH w wydaniu 8.8 (wrzesień 2021) definitywnie wyłączył domyślną obsługę sygnatur ssh-rsa ze względu na podatność skrótu SHA-1 na ataki kolizyjne (atak SHAttered);
    • Klucze RSA 4096-bitowe generują wysoki narzut obliczeniowy i obciążają procesor przy intensywnym nawiązywaniu sesji.
  • Triumf krzywych Edwardsa – Ed25519:
    • Klucz ma stałą długość zaledwie 256 bitów (32 bajty), oferując siłę kryptograficzną porównywalną z ~3072–4096 bitami RSA;
    • Niezrównana szybkość generowania par kluczy, podpisywania oraz weryfikacji sygnatur cyfrowych;
    • Determinizm matematyczny wykluczający kradzież klucza wskutek błędów generatora liczb losowych (problem znany z ECDSA);
    • Pełna odporność na kryptoanalizę czasową (wykonywanie operacji w ściśle stałym czasie zegarowym).
  • Rekomendowane polecenie generowania klucza:
    ssh-keygen -t ed25519 -a 100 -C "admin@domena.pl" (parametr -a 100 wymusza 100 rund funkcji bcrypt KDF do ochrony klucza na dysku).
Odejście od RSA na rzecz Ed25519: Slajd przedstawia zagadnienie Nowoczesne algorytmy kluczy w standardzie OpenSSH w ramach tematu Odejście od RSA na rzecz Ed25519 na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Odejście od RSA - krzywe eliptyczne
13/49
Hardening SSH - dlaczego to konieczne?
Cel slajdu: Slajd omawia zagadnienie „Hardening SSH - dlaczego to konieczne?” w kontekście: Wzmacnianie bezpieczeństwa demona OpenSSH.

Wzmacnianie bezpieczeństwa demona OpenSSH

  • Rzeczywistość sieci publicznych:
    • Każdy serwer z otwartym portem 22 staje się celem automatycznych skanerów i botnetów w ciągu kilkunastu minut od uruchomienia;
    • Dzienniki zdarzeń zapełniają się dziesiątkami tysięcy nieudanych prób logowania słownikowego i brute-force na konta takie jak root, admin, test czy user;
    • Ujawnienie domyślnej konfiguracji grozi kompromitacją infrastruktury w przypadku użycia słabego hasła przez dowolnego użytkownika.
  • Zasada minimalizacji powierzchni ataku (Attack Surface Reduction):
    • W środowisku produkcyjnym demon SSH nie może działać na domyślnych, nadmiarowych ustawieniach dystrybucyjnych;
    • Należy bezwzględnie wyeliminować podatne metody uwierzytelniania (hasła), zablokować uprzywilejowane tożsamości oraz ograniczyć dozwolone algorytmy kryptograficzne wyłącznie do bezpiecznych zestawów (ang. crypto policy).
  • Audyt stanu konfiguracji: polecenie sshd -T pozwala na zrzut efektywnej, aktualnie interpretowanej konfiguracji demona wraz z domyślnymi wartościami dyrektyw.
Hardening SSH - dlaczego to konieczne?: Slajd przedstawia zagadnienie Wzmacnianie bezpieczeństwa demona OpenSSH w ramach tematu Hardening SSH - dlaczego to konieczne? na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Hardening SSH - dlaczego to konieczne?
14/49
Plik sshd_config - centrum dowodzenia
Cel slajdu: Slajd omawia zagadnienie „Plik sshd_config - centrum dowodzenia” w kontekście: Główny plik konfiguracji serwera SSH.

Główny plik konfiguracji serwera SSH

  • Lokalizacja konfiguracji serwera:
    • Główny plik konfiguracyjny: /etc/ssh/sshd_config;
    • Nowoczesna architektura modułowa: katalog /etc/ssh/sshd_config.d/*.conf włączany dyrektywą Include /etc/ssh/sshd_config.d/*.conf na początku pliku;
    • Prawa dostępu do pliku muszą być ściśle chronione: chmod 600 lub chmod 644, właścicielem musi być root:root.
  • Procedura bezpiecznej modyfikacji:
    • 1. Wykonanie kopii zapasowej przed edycją: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak;
    • 2. Bezwzględne sprawdzenie poprawności składni: sudo sshd -t (brak komunikatów oznacza poprawną składnię; kod wyjścia 0);
    • 3. Bezpieczne przeładowanie usługi: sudo systemctl reload ssh (w dystrybucjach z rodziny Red Hat usługa nazywa się sshd; przeładowanie zachowuje aktywne połączenia i zapobiega odcięciu administratora w razie błędu);
    • 4. Test nowego połączenia w osobnym oknie terminala bez zamykania bieżącej sesji roboczej!
Plik sshd_config - centrum dowodzenia: Slajd przedstawia zagadnienie Główny plik konfiguracji serwera SSH w ramach tematu Plik sshd_config - centrum dowodzenia na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Plik sshd_config - centrum dowodzenia
15/49
Wyłączenie logowania hasłem
Cel slajdu: Slajd omawia zagadnienie „Wyłączenie logowania hasłem” w kontekście: Logowanie wyłącznie kluczem kryptograficznym.

Logowanie wyłącznie kluczem kryptograficznym

  • Kluczowe dyrektywy wyłączające hasła w sshd_config:
    • PasswordAuthentication no – wyłącza standardowe uwierzytelnianie hasłem systemowym;
    • KbdInteractiveAuthentication no – blokuje interaktywne zapytania klawiaturowe (w starszych wydaniach pod nazwą ChallengeResponseAuthentication no – nazwa przestarzała, zachowana dla zgodności);
    • PubkeyAuthentication yes – aktywuje uwierzytelnianie kluczami asymetrycznymi;
    • AuthenticationMethods publickey – wymusza, aby jedyną dopuszczalną metodą autoryzacji był klucz publiczny.
  • Zalety wyłączenia haseł:
    • Całkowite uodpornienie serwera na ataki słownikowe, ataki brute-force oraz wycieki baz poświadczeń (ang. credential stuffing);
    • Eliminacja ryzyka podsłuchu hasła przez keyloggery na stacjach roboczych;
    • Jest to krok wspierający spełnienie wymagań norm ISO/IEC 27001 oraz PCI DSS (samo wyłączenie haseł nie zapewnia pełnej zgodności).
  • Warunek krytyczny: przed restartem upewnij się, że twój klucz publiczny znajduje się w ~/.ssh/authorized_keys i potrafisz się nim zalogować!
Wyłączenie logowania hasłem: Slajd przedstawia zagadnienie Logowanie wyłącznie kluczem kryptograficznym w ramach tematu Wyłączenie logowania hasłem na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Wyłączenie logowania hasłem
16/49
Blokada logowania na konto root
Cel slajdu: Slajd omawia zagadnienie „Blokada logowania na konto root” w kontekście: Zakaz bezpośredniego logowania administratora root przez SSH.

Zakaz bezpośredniego logowania administratora root przez SSH

  • Konto superużytkownika (UID 0):
    • Nazwa konta root jest identyczna na każdym systemie uniksowym i stanowi pierwszy cel ataków zautomatyzowanych;
    • Bezpośrednie logowanie na konto root uniemożliwia rzetelny audyt (w logach nie ma informacji, który z administratorów faktycznie wykonał operację).
  • Warianty dyrektywy PermitRootLogin w sshd_config:
    • PermitRootLogin no – wariant zalecany: całkowity zakaz logowania roota przez sieć;
    • PermitRootLogin prohibit-password (lub without-password) – root może logować się wyłącznie zaufanym kluczem publicznym (często stosowane w automatyzacji kopii zapasowych lub klastrach Ansible);
    • PermitRootLogin yes – ustawienie wysoce niebezpieczne, absolutnie zabronione na produkcji.
  • Zalecany wzorzec operacyjny:
    • Administrator loguje się na imienne konto ze zwykłymi uprawnieniami (np. jnowak) przy użyciu klucza Ed25519;
    • Podniesienie uprawnień do zadań administracyjnych następuje przez mechanizm sudo lub doas z rejestracją poleceń w logach audytowych.
Blokada logowania na konto root: Slajd przedstawia zagadnienie Zakaz bezpośredniego logowania administratora root przez SSH w ramach tematu Blokada logowania na konto root na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Blokada logowania na konto root
17/49
Ograniczenie dostępu przez AllowGroups
Cel slajdu: Slajd omawia zagadnienie „Ograniczenie dostępu przez AllowGroups” w kontekście: Dostęp SSH tylko dla wybranych grup i użytkowników.

Dostęp SSH tylko dla wybranych grup i użytkowników

  • Mechanizm list kontroli dostępu (ACL) w OpenSSH:
    • Domyślnie każdy użytkownik posiadający konto w systemie (i ważną powłokę shell) ma techniczną możliwość podjęcia próby logowania przez SSH;
    • Dyrektywy filtrujące pozwalają na precyzyjne ograniczenie kręgu uprawnionych tożsamości.
  • Hierarchia dyrektyw w sshd_config:
    • AllowGroups ssh-users – dostęp uzyskują wyłącznie konta będące członkami grupy systemowej ssh-users;
    • AllowUsers admin1 admin2@192.0.2.50 – zezwala na logowanie konkretnym użytkownikom, opcjonalnie z maską adresu IP;
    • DenyUsers oraz DenyGroups – listy tożsamości bezwzględnie blokowanych.
  • Kolejność ewaluacji reguł w OpenSSH:
    1. DenyUsers → 2. AllowUsers → 3. DenyGroups → 4. AllowGroups.
    Jeśli zdefiniowano dyrektywy typu Allow, żaden inny użytkownik nie uzyska dostępu.
  • Procedura wdrożenia:
    sudo groupadd ssh-users
    sudo usermod -aG ssh-users jnowak
Ograniczenie dostępu przez AllowGroups: Slajd przedstawia zagadnienie Dostęp SSH tylko dla wybranych grup i użytkowników w ramach tematu Ograniczenie dostępu przez AllowGroups na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Ograniczenie dostępu przez AllowGroups
18/49
Zmiana domyślnego portu SSH
Cel slajdu: Slajd omawia zagadnienie „Zmiana domyślnego portu SSH” w kontekście: Niestandardowy port SSH dla bezpieczeństwa.

Niestandardowy port SSH dla bezpieczeństwa

  • Dyrektywa konfiguracyjna: Port 51022 w pliku sshd_config (zalecany wysoki port z puli prywatnej/dynamicznej: 49152–65535).
  • Rzeczywiste korzyści ze zmiany portu:
    • Drastyczna redukcja szumu w logach: eliminacja ponad 99% automatycznych skanerów i prymitywnych botnetów skanujących wyłącznie port 22/TCP;
    • Zmniejszenie obciążenia procesora i pamięci serwera ciągłym nawiązywaniem i zrywaniem sesji handshake przez boty;
    • Ułatwienie analizy incydentów bezpieczeństwa – w logach widoczne są tylko celowe, ukierunkowane próby połączeń.
  • Pułapka „Security through obscurity” (bezpieczeństwo przez niejawność):
    • Zmiana portu nie jest samodzielnym mechanizmem kryptograficznym ani ochroną przed zdeterminowanym atakującym;
    • Zaawansowane skanery (np. Nmap z wykrywaniem usług, nmap -sV -p 51022 adres-serwera) bez trudu identyfikują nagłówek powitalny SSH niezależnie od numeru portu.
  • Niezbędne kroki towarzyszące:
    • Dostosowanie reguł zapory ogniowej: sudo ufw allow 51022/tcp (Debian/Ubuntu) lub firewall-cmd --add-port=51022/tcp --permanent (dystrybucje z rodziny Red Hat);
    • Kontekst SELinux (RHEL/CentOS/Rocky): semanage port -a -t ssh_port_t -p tcp 51022.
Zmiana domyślnego portu SSH: Slajd przedstawia zagadnienie Niestandardowy port SSH dla bezpieczeństwa w ramach tematu Zmiana domyślnego portu SSH na przykładach poleceń oraz diagnostyki w systemach Linux, Windows i RouterOS. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Zmiana domyślnego portu SSH
19/49
Dodatkowe dyrektywy hardeningu
Cel slajdu: Slajd omawia zagadnienie „Dodatkowe dyrektywy hardeningu” w kontekście: Zaawansowane opcje bezpieczeństwa SSH.

Zaawansowane opcje bezpieczeństwa SSH

  • Ograniczenie liczby prób i czasu na autoryzację:
    • MaxAuthTries 3 – po 3 nieudanych próbach uwierzytelnienia połączenie TCP jest natychmiast zrywane;
    • LoginGraceTime 30 – klient ma maksymalnie 30 sekund na ukończenie procesu logowania (ochrona przed atakami wyczerpania zasobów DoS).
  • Zarządzanie bezczynnością i zrywaniem wiszących sesji:
    • ClientAliveInterval 300 i ClientAliveCountMax 2 – serwer wysyła szyfrowany pakiet kontrolny co 5 minut; brak odpowiedzi przez 2 kolejne cykle (10 minut) powoduje bezpieczne zamknięcie sesji;
    • Zapobiega pozostawianiu otwartych konsoli administracyjnych na opuszczonych stacjach roboczych.
  • Wyłączenie zbędnych i ryzykownych podsystemów:
    • X11Forwarding no – wyłącza przekierowanie graficznego środowiska X11 (eliminuje ryzyko kradzieży wciśnięć klawiszy i zrzutów ekranu przez złośliwy serwer X);
    • MaxStartups 10:30:100 – ogranicza liczbę jednoczesnych nieuwierzytelnionych połączeń (mitigacja ataków DDoS);
    • PrintMotd no oraz PrintLastLog no – ogranicza ujawnianie szczegółów środowiska systemowego.
Dodatkowe dyrektywy hardeningu: Slajd przedstawia zagadnienie Zaawansowane opcje bezpieczeństwa SSH w ramach tematu Dodatkowe dyrektywy hardeningu na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Dodatkowe dyrektywy hardeningu
20/49
Podsumowanie hardeningu - wzorcowa konfiguracja
Cel slajdu: Slajd omawia zagadnienie „Podsumowanie hardeningu - wzorcowa konfiguracja” w kontekście: Wzór bezpiecznej konfiguracji SSH.

Wzór bezpiecznej konfiguracji SSH

  • Wzorcowy plik produkcyjny /etc/ssh/sshd_config:
# Podstawowe parametry sieciowe
Port 51022
AddressFamily inet
ListenAddress 0.0.0.0

# Klucze hosta serwera
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Bezwzględna kontrola uwierzytelniania
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitEmptyPasswords no

# Kontrola dostępu i limity
AllowGroups ssh-users
MaxAuthTries 3
LoginGraceTime 30
MaxSessions 5

# Utrzymanie sesji i eliminacja zagrożeń
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowAgentForwarding no
LogLevel VERBOSE
  • Pamiętaj o obowiązkowej walidacji składni: sudo sshd -t przed wydaniem polecenia sudo systemctl reload sshd.
Podsumowanie hardeningu - wzorcowa konfiguracja: Slajd przedstawia zagadnienie Wzór bezpiecznej konfiguracji SSH w ramach tematu Podsumowanie hardeningu - wzorcowa konfiguracja na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Podsumowanie hardeningu - wzorcowa konfiguracja
21/49
SSH Tunneling - koncepcja
Cel slajdu: Slajd omawia zagadnienie „SSH Tunneling - koncepcja” w kontekście: Tunelowanie portów przez SSH.

Tunelowanie portów przez SSH

  • Koncepcja Port Forwardingu:
    • SSH Tunneling (przekierowanie portów) to mechanizm hermetyzacji dowolnego strumienia danych TCP wewnątrz bezpiecznego, zaszyfrowanego i uwierzytelnionego kanału SSH;
    • Opiera się na specyfikacji warstwy połączenia Connection Layer (RFC 4254), która zarządza logicznymi kanałami transmisji (ang. channels).
  • Główne scenariusze zastosowania w inżynierii sieciowej:
    • Szyfrowanie podatnego ruchu: zabezpieczenie protokołów przesyłających dane otwartym tekstem (nieszyfrowane panele HTTP, starsze wersje protokołów bazodanowych, usługi telemetrii);
    • Bezpieczny dostęp do stref chronionych: łączenie się z usługami nasłuchującymi wyłącznie na pętli zwrotnej 127.0.0.1 lub w prywatnych podsieciach VLAN bez publicznych adresów IP;
    • Transparentne omijanie barier sieciowych: bezpieczne przebijanie się przez translację adresów NAT oraz restrykcyjne zapory ogniowe (firewalls) zezwalające wyłącznie na wychodzący ruch TCP/22.
  • Trzy podstawowe architektury tunelowania:
    • Przekierowanie lokalne (Local Forwarding -L);
    • Przekierowanie zdalne (Remote Forwarding -R);
    • Przekierowanie dynamiczne (Dynamic Forwarding -D – proxy SOCKS5).
SSH Tunneling - koncepcja: Slajd przedstawia zagadnienie Tunelowanie portów przez SSH w ramach tematu SSH Tunneling - koncepcja na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
SSH Tunneling - koncepcja
22/49
Local Forwarding - tunel lokalny
Cel slajdu: Slajd omawia zagadnienie „Local Forwarding - tunel lokalny” w kontekście: Przekierowanie lokalne w SSH.

Przekierowanie lokalne w SSH

  • Składnia polecenia:
    ssh -L [adres_lokalny:]port_lokalny:host_docelowy:port_docelowy uzytkownik@serwer_ssh
  • Zasada działania tunelu lokalnego:
    • Klient SSH otwiera gniazdo nasłuchujące na stacji lokalnej (domyślnie 127.0.0.1:port_lokalny);
    • Aplikacja na stacji administratora łączy się z portem lokalnym;
    • Klient SSH szyfruje odebrany strumień TCP i przesyła go tunelem SSH do serwera SSH;
    • Serwer SSH odszyfrowuje dane i w imieniu klienta nawiązuje klasyczne połączenie TCP z host_docelowy:port_docelowy.
  • Kluczowa cecha rezolucji nazw DNS:
    • Adres host_docelowy jest tłumaczony przez serwer DNS z perspektywy serwera SSH, a nie stacji klienckiej;
    • Umożliwia to odwoływanie się do wewnętrznych nazw FQDN z prywatnych stref DNS dostępnych wyłącznie w sieci serwera.
Local Forwarding - tunel lokalny: Slajd przedstawia zagadnienie Przekierowanie lokalne w SSH w ramach tematu Local Forwarding - tunel lokalny na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Local Forwarding - tunel lokalny
23/49
Local Forwarding - dostęp do MySQL
Cel slajdu: Slajd omawia zagadnienie „Local Forwarding - dostęp do MySQL” w kontekście: Tunel SSH do bazy MySQL.

Tunel SSH do bazy MySQL

  • Scenariusz problemowy w środowisku produkcyjnym:
    • Serwer bazy danych (MySQL / MariaDB / PostgreSQL) nasłuchuje na domyślnym porcie 3306 wyłącznie na adresie pętli zwrotnej 127.0.0.1 (parametr bind-address = 127.0.0.1);
    • Zapora sieciowa (firewall) bezwzględnie blokuje dostęp z Internetu do portu bazy danych;
    • Inżynier musi uzyskać dostęp za pomocą graficznego narzędzia administracyjnego (np. DBeaver, MySQL Workbench, DataGrip) uruchomionego na własnej stacji roboczej.
  • Wzorcowe polecenie zestawienia tunelu:
    ssh -L 13306:127.0.0.1:3306 -N -f admin@serwer-app.pl
  • Wyjaśnienie użytych flag konfiguracyjnych:
    • -L 13306:127.0.0.1:3306 – przekierowuje lokalny port 13306 na zdalny port 3306 pętli zwrotnej serwera;
    • -N (No command) – instruuje klienta, aby nie uruchamiał zdalnej powłoki shell (tunel dedykowany);
    • -f (Fork into background) – przenosi proces SSH w tło po pomyślnym uwierzytelnieniu sesji.
  • Konfiguracja aplikacji klienckiej: Host: 127.0.0.1, Port: 13306.
Local Forwarding - dostęp do MySQL: Slajd przedstawia zagadnienie Tunel SSH do bazy MySQL w ramach tematu Local Forwarding - dostęp do MySQL na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Local Forwarding - dostęp do MySQL
24/49
Local Forwarding - wiele tuneli
Cel slajdu: Slajd omawia zagadnienie „Local Forwarding - wiele tuneli” w kontekście: Wiele przekierowań lokalnych w jednej sesji SSH.

Wiele przekierowań lokalnych w jednej sesji SSH

  • Multipleksowanie wielu tuneli w pojedynczym procesie:
    • Klient OpenSSH pozwala na zdefiniowanie wielu flag -L w ramach jednego wywołania wiersza poleceń;
    • Wszystkie zdefiniowane tunele są przesyłane wewnątrz tego samego, pojedynczego połączenia TCP i współdzielą jedną sesję kryptograficzną.
  • Przykład polecenia dla infrastruktury wielowarstwowej:
    ssh -N -f \
      -L 8080:10.0.1.10:80 \
      -L 13306:10.0.2.20:3306 \
      -L 15432:10.0.2.30:5432 \
      admin@brama-bastion.firma.pl
  • Konfiguracja deklaratywna w pliku ~/.ssh/config:
Host brama-produkcyjna
    HostName brama-bastion.firma.pl
    User admin
    IdentityFile ~/.ssh/id_ed25519
    LocalForward 8080 10.0.1.10:80
    LocalForward 13306 10.0.2.20:3306
    LocalForward 15432 10.0.2.30:5432
  • Uruchomienie całego zestawu tuneli sprowadza się do zwięzłego polecenia: ssh -N -f brama-produkcyjna.
Local Forwarding - wiele tuneli: Slajd przedstawia zagadnienie Wiele przekierowań lokalnych w jednej sesji SSH w ramach tematu Local Forwarding - wiele tuneli na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Local Forwarding - wiele tuneli
25/49
Remote Forwarding - tunel odwrotny
Cel slajdu: Slajd omawia zagadnienie „Remote Forwarding - tunel odwrotny” w kontekście: Przekierowanie zdalne w SSH.

Przekierowanie zdalne w SSH

  • Składnia polecenia:
    ssh -R [adres_zdalny:]port_zdalny:host_docelowy:port_docelowy uzytkownik@serwer_ssh
  • Zasada działania tunelu zdalnego (Reverse Tunnel):
    • Proces klienta SSH nakazuje serwerowi SSH otwarcie gniazda nasłuchującego na maszynie zdalnej (domyślnie 127.0.0.1:port_zdalny);
    • Gdy na serwerze zdalnym pojawi się połączenie na porcie port_zdalny, ruch jest przesyłany tunelem SSH w kierunku przeciwnym – do stacji klienta;
    • Klient SSH odbiera pakiety i przekazuje je do host_docelowy:port_docelowy (zazwyczaj usługi na własnym komputerze lub w lokalnej sieci LAN).
  • Zastosowanie: umożliwia udostępnienie lokalnej usługi działającej na stacji inżyniera użytkownikom lub aplikacjom znajdującym się w sieci serwera zdalnego.
Remote Forwarding - tunel odwrotny: Slajd przedstawia zagadnienie Przekierowanie zdalne w SSH w ramach tematu Remote Forwarding - tunel odwrotny na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Remote Forwarding - tunel odwrotny
26/49
Remote Forwarding - omijanie NAT
Cel slajdu: Slajd omawia zagadnienie „Remote Forwarding - omijanie NAT” w kontekście: Tunel odwrotny przez translację NAT i zapory ogniowe.

Tunel odwrotny przez translację NAT i zapory ogniowe

  • Problem asymetrii w sieciach brzegowych:
    • Stacje robocze, serwery wewnątrz sieci firmowych oraz węzły brzegowe (np. w sieciach komórkowych 4G/5G) znajdują się za translacją adresów NAT / CGNAT;
    • Brak publicznego adresu IP oraz blokada połączeń przychodzących na routerach uniemożliwia bezpośrednie połączenie z zewnątrz (np. z Internetu do stacji w biurze).
  • Rozwiązanie oparte na tunelu odwrotnym:
    • Stacja znajdująca się za NAT-em inicjuje połączenie wychodzące (które zapory ogniowe zazwyczaj bez przeszkód przepuszczają) do serwera z publicznym IP;
    • Polecenie na stacji wewnętrznej:
      ssh -N -f -R 2222:127.0.0.1:22 admin@publiczny-serwer.pl;
    • Na publicznym serwerze otwiera się port 2222, który jest trwale połączony z portem 22 lokalnej maszyny ukrytej za NAT-em.
  • Uzyskanie zdalnego dostępu: z poziomu publicznego serwera wystarczy wydać polecenie ssh -p 2222 uzytkownik@127.0.0.1, aby zalogować się na komputer za NAT-em!
Remote Forwarding - omijanie NAT: Slajd przedstawia zagadnienie Tunel odwrotny przez translację NAT i zapory ogniowe w ramach tematu Remote Forwarding - omijanie NAT na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Remote Forwarding - omijanie NAT
27/49
Remote Forwarding - scenariusz produkcyjny
Cel slajdu: Slajd omawia zagadnienie „Remote Forwarding - scenariusz produkcyjny” w kontekście: Zdalny tunel w praktyce inżynierskiej.

Zdalny tunel w praktyce inżynierskiej

  • Scenariusz 1: Lokalne testowanie webhooków zewnętrznych:
    • Integracja z bramkami płatności lub platformami chmurowymi (np. powiadomienia webhook);
    • Serwer chmurowy musi przesłać zapytanie HTTP POST do aplikacji deweloperskiej uruchomionej na laptopie inżyniera: ssh -R 8080:127.0.0.1:3000 user@chmura.pl.
  • Scenariusz 2: Zdalne zarządzanie urządzeniami IoT i brzegowymi (Edge):
    • Sterowniki przemysłowe, węzły pomiarowe i centrale zainstalowane w terenie z modemami LTE;
    • Urządzenie po uruchomieniu automatycznie zestawia tunel zwrotny do centralnego serwera zarządzania.
  • Utrzymanie stabilności tunelu – narzędzie autossh:
    • Standardowe połączenie SSH może ulec zawieszeniu po chwilowej utracie zasięgu lub przełączeniu stacji bazowej;
    • Narzędzie autossh monitoruje stan tunelu za pomocą dedykowanych pakietów echa i natychmiast restartuje proces w razie awarii:
autossh -M 0 -N -f -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" \
  -R 2222:127.0.0.1:22 admin@serwer-hub.pl
Remote Forwarding - scenariusz produkcyjny: Slajd przedstawia zagadnienie Zdalny tunel w praktyce inżynierskiej w ramach tematu Remote Forwarding - scenariusz produkcyjny na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Remote Forwarding - scenariusz produkcyjny
28/49
Dynamic Forwarding - SOCKS5 proxy
Cel slajdu: Slajd omawia zagadnienie „Dynamic Forwarding - SOCKS5 proxy” w kontekście: Proxy SOCKS5 przez SSH.

Proxy SOCKS5 przez SSH

  • Składnia polecenia:
    ssh -D [adres_lokalny:]port_lokalny uzytkownik@serwer_ssh
  • Zasada działania tunelowania dynamicznego:
    • Klient SSH uruchamia na wskazanym porcie stacji roboczej (np. 127.0.0.1:1080) pełnoprawny serwer proxy zgodny ze standardem SOCKS5 (RFC 1928);
    • Brak statycznie zdefiniowanego celu: aplikacja kliencka dynamicznie informuje proxy, z jakim docelowym adresem IP i portem TCP chce nawiązać połączenie;
    • Klient SSH przekazuje żądanie tunelem do zdalnego serwera SSH, który nawiązuje docelowe połączenie w imieniu aplikacji.
  • Wzorcowe polecenie uruchomienia proxy:
    ssh -D 1080 -N -f admin@serwer-brama.pl
  • Zastosowanie:
    • Błyskawiczne stworzenie bezpiecznego tunelu dla całego ruchu przeglądarki podczas korzystania z niezaufanych publicznych sieci Wi-Fi (hotele, kawiarnie, lotniska);
    • Transparentny dostęp do całych podsieci intranetowych bez konieczności definiowania setek osobnych tuneli statycznych -L.
Dynamic Forwarding - SOCKS5 proxy: Slajd przedstawia zagadnienie Proxy SOCKS5 przez SSH w ramach tematu Dynamic Forwarding - SOCKS5 proxy na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Dynamic Forwarding - SOCKS5 proxy
29/49
SOCKS5 - konfiguracja przeglądarki
Cel slajdu: Slajd omawia zagadnienie „SOCKS5 - konfiguracja przeglądarki” w kontekście: Przeglądarka przez tunel SOCKS5.

Przeglądarka przez tunel SOCKS5

  • Konfiguracja przeglądarki Mozilla Firefox (zalecana):
    • Ustawienia → Ustawienia sieciowe → Ręczna konfiguracja serwerów pośredniczących;
    • Serwer proxy SOCKS: 127.0.0.1, Port: 1080, wersja: SOCKS v5;
    • Kluczowy warunek bezpieczeństwa: zaznacz opcję „Proxy DNS przy użyciu SOCKS v5” (dyrektywa network.proxy.socks_remote_dns = true w about:config).
  • Zagrożenie wyciekiem zapytań DNS (DNS Leak):
    • Jeżeli DNS nie jest tunelowany przez SOCKS5, stacja wysyła zapytania o nazwy domenowe do lokalnego resolvera w sieci Wi-Fi w postaci jawnej;
    • Lokalny podsłuchujący widzi wszystkie odwiedzane domeny pomimo szyfrowania ruchu HTTP/HTTPS!
  • Wywołanie narzędzi wiersza poleceń przez proxy z ochroną DNS:
    curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me
    (parametr --socks5-hostname wymusza rozwiązanie nazwy przez serwer zdalny).
SOCKS5 - konfiguracja przeglądarki: Slajd przedstawia zagadnienie Przeglądarka przez tunel SOCKS5 w ramach tematu SOCKS5 - konfiguracja przeglądarki na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
SOCKS5 - konfiguracja przeglądarki
30/49
Porównanie typów tunelowania SSH
Cel slajdu: Slajd omawia zagadnienie „Porównanie typów tunelowania SSH” w kontekście: Lokalny, zdalny i dynamiczny w SSH.

Lokalny, zdalny i dynamiczny w SSH

  • Matryca porównawcza architektur tunelowania:
Cecha Local (-L) Remote (-R) Dynamic (-D)
Port nasłuchujący Na stacji klienta Na serwerze zdalnym Na stacji klienta
Kierunek ruchu Klient → Serwer → Cel Serwer → Klient → Cel Klient → Serwer → Dynamiczny
Definicja celu Statyczna (host:port) Statyczna (host:port) Dynamiczna (SOCKS5)
Typowe użycie Dostęp do baz danych w LAN Omijanie NAT / dostęp do IoT Bezpieczny Internet / Wi-Fi
Porównanie typów tunelowania SSH: Slajd przedstawia zagadnienie Lokalny, zdalny i dynamiczny w SSH w ramach tematu Porównanie typów tunelowania SSH na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Porównanie typów tunelowania SSH
31/49
GatewayPorts - udostępnianie tuneli innym
Cel slajdu: Slajd omawia zagadnienie „GatewayPorts - udostępnianie tuneli innym” w kontekście: Udostępnianie tuneli SSH w sieci lokalnej.

Udostępnianie tuneli SSH w sieci lokalnej

  • Domyślna polityka izolacji gniazd sieciowych:
    • Domyślnie klient i serwer OpenSSH wiążą otwierane porty tuneli (zarówno -L, jak i -R) wyłącznie z adresem pętli zwrotnej 127.0.0.1;
    • Oznacza to, że z tunelu może skorzystać wyłącznie proces uruchomiony na tej samej maszynie.
  • Dyrektywa serwerowa GatewayPorts w pliku sshd_config:
    • GatewayPorts no (wartość domyślna) – tunele zdalne -R mogą nasłuchiwać tylko na adresie localhost serwera;
    • GatewayPorts yes – demon wymusza wiązanie portów zdalnych ze wszystkimi interfejsami (0.0.0.0), udostępniając tunel w sieci;
    • GatewayPorts clientspecified (wariant zalecany) – serwer pozwala klientowi samodzielnie zadecydować, z jakim adresem IP powiązać tunel.
  • Udostępnienie tunelu zdalnego dla stacji w sieci LAN:
    ssh -R 0.0.0.0:8080:127.0.0.1:80 admin@serwer-hub.pl
  • Zagrożenie bezpieczeństwa: udostępnienie tunelu na 0.0.0.0 otwiera port dla każdego węzła w sieci – wymagana jest kontrola zaporą ogniową!
GatewayPorts - udostępnianie tuneli innym: Slajd przedstawia zagadnienie Udostępnianie tuneli SSH w sieci lokalnej w ramach tematu GatewayPorts - udostępnianie tuneli innym na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
GatewayPorts - udostępnianie tuneli innym
32/49
Tunelowanie przez jump host (bastion)
Cel slajdu: Slajd omawia zagadnienie „Tunelowanie przez jump host (bastion)” w kontekście: Bastion SSH jako brama przesiadkowa.

Bastion SSH jako brama przesiadkowa

  • Architektura strefy DMZ i bastionu (Jump Host / Bastion Host):
    • Serwery produkcyjne i bazy danych znajdują się w odizolowanych podsieciach prywatnych bez publicznych adresów IP;
    • Jedynym punktem wejścia z Internetu jest rygorystycznie utwardzony serwer pośredniczący (Bastion);
    • Inżynier nie może bezpośrednio zaadresować serwera docelowego w warstwie IP.
  • Nowoczesne rozwiązanie OpenSSH – flaga -J (ProxyJump):
    ssh -J admin@bastion.firma.pl:51022 dbuser@10.0.2.50
    • Mechanizm działa w oparciu o opcję ssh -W %h:%p bastion;
    • Klient zestawia zaszyfrowany kanał do bastionu, przez który transparentnie przesyła drugi, niezależny tunel SSH bezpośrednio do serwera docelowego.
  • Kluczowa zaleta kryptograficzna:
    • Sesja SSH jest szyfrowana end-to-end pomiędzy stacją inżyniera a serwerem docelowym;
    • Administrator bastionu nie ma wglądu w przesyłane dane ani nie posiada kluczy prywatnych użytkownika!
  • Łańcuch wielu bastionów: ssh -J host1,host2,host3 target.
Tunelowanie przez jump host (ang. bastion): Slajd przedstawia zagadnienie Bastion SSH jako brama przesiadkowa w ramach tematu Tunelowanie przez jump host (bastion) na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Tunelowanie przez jump host (bastion)
33/49
SSH Agent Forwarding
Cel slajdu: Slajd omawia zagadnienie „SSH Agent Forwarding” w kontekście: Przekazywanie agenta SSH i związane z nim ryzyka.

Przekazywanie agenta SSH i związane z nim ryzyka

  • Rola mechanizmu Agent Forwarding (ssh -A):
    • Pozwala na udostępnienie lokalnego demona ssh-agent na zdalnym serwerze podczas kolejnych skoków sieciowych;
    • Klucze prywatne nie są kopiowane na serwer pośredniczący – zdalny proces prosi lokalnego agenta o wykonanie podpisu kryptograficznego;
    • Włączanie: flaga ssh -A lub dyrektywa ForwardAgent yes w pliku konfiguracyjnym.
  • Poważne zagrożenie bezpieczeństwa (Wektor ataku na gniazdo agenta):
    • Gdy włączone jest przekazywanie agenta, demon SSH tworzy na zdalnej maszynie gniazdo uniksowe (zmienna SSH_AUTH_SOCK w /tmp/ssh-...);
    • Użytkownik z uprawnieniami root na serwerze pośredniczącym może uzyskać dostęp do tego gniazda i używać twojego lokalnego agenta do autoryzacji na dowolnych innych serwerach w infrastrukturze tak długo, jak trwa twoje połączenie!
  • Rekomendacja inżynierska:
    • Unikaj ssh -A; zamiast tego stosuj ssh -J (ProxyJump);
    • Jeśli musisz użyć agenta, dodawaj klucze z flagą potwierdzenia: ssh-add -c (każde użycie wymaga akceptacji w oknie dialogowym).
SSH Agent Forwarding: Slajd przedstawia zagadnienie Przekazywanie agenta SSH i związane z nim ryzyka w ramach tematu SSH Agent Forwarding na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
SSH Agent Forwarding
34/49
SSH Config - zaawansowana konfiguracja klienta
Cel slajdu: Slajd omawia zagadnienie „SSH Config - zaawansowana konfiguracja klienta” w kontekście: Plik konfiguracyjny klienta ~/.ssh/config.

Plik konfiguracyjny klienta ~/.ssh/config

  • Centralizacja zarządzania połączeniami:
    • Plik ~/.ssh/config pozwala na zdefiniowanie aliasów, specyficznych portów, kluczy tożsamości oraz tuneli dla poszczególnych serwerów;
    • Eliminuje konieczność pamiętania i ręcznego wpisywania skomplikowanych parametrów wiersza poleceń;
    • Uprawnienia do pliku muszą być bezwzględnie ustawione na chmod 600 ~/.ssh/config.
  • Przykładowa profesjonalna konfiguracja wieloserwerowa:
# Parametry domyślne dla wszystkich połączeń
Host *
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 3
    ForwardAgent no
    AddKeysToAgent yes

# Serwer przesiadkowy (Bastion)
Host bastion
    HostName bastion.firma.pl
    Port 51022
    User admin
    IdentityFile ~/.ssh/id_ed25519_bastion

# Wewnętrzna baza danych dostępna wyłącznie przez bastion
Host prod-db
    HostName 10.0.2.50
    User dbadmin
    IdentityFile ~/.ssh/id_ed25519_prod
    ProxyJump bastion
    LocalForward 13306 127.0.0.1:3306
  • Połączenie i zestawienie tunelu sprowadza się do prostego: ssh prod-db.
SSH Config - zaawansowana konfiguracja klienta: Slajd przedstawia zagadnienie Plik konfiguracyjny klienta ~/.ssh/config w ramach tematu SSH Config - zaawansowana konfiguracja klienta na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
SSH Config - zaawansowana konfiguracja klienta
35/49
SSH Certificates - zarządzanie zaufaniem
Cel slajdu: Slajd omawia zagadnienie „SSH Certificates - zarządzanie zaufaniem” w kontekście: Certyfikaty SSH dla skalowalności infrastruktury.

Certyfikaty SSH dla skalowalności infrastruktury

  • Ograniczenia tradycyjnego modelu kluczy asymetrycznych:
    • Zarządzanie plikami authorized_keys na tysiącach serwerów staje się koszmarem logistycznym (problem rotacji i unieważniania kluczy);
    • Model TOFU w known_hosts jest podatny na błędy ludzkie przy weryfikacji serwerów.
  • Natywne certyfikaty OpenSSH (to nie są certyfikaty X.509!):
    • Prosty, zwięzły format kryptograficzny zintegrowany z OpenSSH;
    • Klucz użytkownika lub hosta jest kryptograficznie podpisywany przez zaufany Urząd Certyfikacji (SSH CA);
    • Certyfikat zawiera metadane: dozwolone nazwy użytkowników (principals), czas ważności (np. 8 godzin) oraz opcje ograniczeń.
  • Wzorcowe polecenie podpisania klucza przez CA:
    ssh-keygen -s /etc/ssh/ca_user_key -I jan_nowak -n jnowak,admin \
      -V +1d -z 1001 id_ed25519.pub
  • Konfiguracja serwera: wystarczy jedna linia w sshd_config:
    TrustedUserCAKeys /etc/ssh/ca_user_key.pub
    Serwer ufa każdemu ważnemu certyfikatowi podpisanemu przez CA – brak konieczności edycji authorized_keys!
SSH Certificates - zarządzanie zaufaniem: Slajd przedstawia zagadnienie Certyfikaty SSH dla skalowalności infrastruktury w ramach tematu SSH Certificates - zarządzanie zaufaniem na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
SSH Certificates - zarządzanie zaufaniem
36/49
SSH w środowisku Windows
Cel slajdu: Slajd omawia zagadnienie „SSH w środowisku Windows” w kontekście: Natywny OpenSSH w systemach Windows 10, 11 i Windows Server.

Natywny OpenSSH w systemach Windows 10, 11 i Windows Server

  • Współczesny standard w ekosystemie Microsoft:
    • Od 2018 roku Microsoft oficjalnie wspiera i dostarcza preinstalowany port OpenSSH jako opcjonalną funkcję systemu Windows;
    • Koniec ery zewnętrznych programów z niekompatybilnymi formatami kluczy (PuTTY .ppk) – natywne wsparcie w konsoli PowerShell i terminalu Windows.
  • Zarządzanie usługą OpenSSH w PowerShell (jako Administrator):
# Instalacja komponentów klienta i serwera OpenSSH (konsola uruchomiona z podwyższonymi uprawnieniami)
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

# Konfiguracja i uruchomienie usługi demona sshd
Set-Service -Name sshd -StartupType 'Automatic'
Start-Service sshd

# Konfiguracja usługi agenta uwierzytelniania
Set-Service -Name ssh-agent -StartupType 'Automatic'
Start-Service ssh-agent
  • Specyfika uprawnień Windows: plik autoryzacyjny dla kont z grupy Administratorzy znajduje się w: %ProgramData%\ssh\administrators_authorized_keys z restrykcyjnymi listami ACL (wyłącznie SYSTEM i Administratorzy).
SSH w środowisku Windows: Slajd przedstawia zagadnienie Natywny OpenSSH w systemach Windows 10, 11 i Windows Server w ramach tematu SSH w środowisku Windows na przykładach poleceń oraz diagnostyki w systemach Linux, Windows i RouterOS. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
SSH w środowisku Windows
37/49
Fail2Ban i sshguard – dodatkowa ochrona
Cel slajdu: Slajd omawia zagadnienie „Fail2Ban i sshguard - dodatkowa ochrona” w kontekście: Automatyczna blokada ataków sieciowych na poziomie hosta.

Automatyczna blokada ataków sieciowych na poziomie hosta

  • Zasada działania aktywnych systemów obronnych (IPS na poziomie hosta):
    • Narzędzia Fail2Ban oraz sshguard monitorują dzienniki systemowe w czasie rzeczywistym (/var/log/auth.log lub strumień systemd-journald);
    • Wykrywają wzorce powtarzających się nieudanych prób logowania (nieprawidłowe klucze, próby logowania na nieistniejące konta);
    • Po przekroczeniu zdefiniowanego progu tolerancji dynamicznie wstrzykują regułę blokującą adres IP intruza do zapory sieciowej (nftables / iptables).
  • Wzorcowa konfiguracja jaila w pliku /etc/fail2ban/jail.local:
[sshd]
enabled = true
port = 51022
filter = sshd
backend = systemd
maxretry = 3
findtime = 600
bantime = 3600
ignoreip = 127.0.0.1/8 ::1 192.0.2.0/24
  • Kluczowe parametry: 3 nieudane próby w ciągu 10 minut skutkują blokadą adresu IP atakującego na 1 godzinę. Parametr ignoreip chroni podsieć administracyjną przed przypadkową blokadą.
Fail2Ban i sshguard - dodatkowa ochrona: Slajd przedstawia zagadnienie Automatyczna blokada ataków sieciowych na poziomie hosta w ramach tematu Fail2Ban i sshguard - dodatkowa ochrona na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Fail2Ban i sshguard - dodatkowa ochrona
38/49
Podsumowanie części tunelowania
Cel slajdu: Slajd omawia zagadnienie „Podsumowanie części tunelowania” w kontekście: Tunelowanie SSH w pigułce inżynierskiej.

Tunelowanie SSH w pigułce inżynierskiej

  • Trzy filary tunelowania OpenSSH:
    • Local Forwarding (-L): bezpieczny dostęp do usług bazodanowych i paneli webowych w odizolowanych podsieciach LAN/DMZ;
    • Remote Forwarding (-R): udostępnianie usług zza podwójnego NAT-u oraz zdalny dostęp telemetryczny do urządzeń brzegowych;
    • Dynamic Forwarding (-D): lokalne proxy SOCKS5 zabezpieczające cały ruch aplikacyjny z ochroną zapytań DNS.
  • Złote zasady bezpieczeństwa tunelowania:
    • Zastępuj przestarzały i ryzykowny mechanizm Agent Forwarding nowoczesnym rozwiązaniem ProxyJump (-J);
    • Nigdy nie włączaj GatewayPorts yes bez restrykcyjnego filtrowania ruchu na zaporze ogniowej;
    • W pliku authorized_keys dla kluczy serwisowych zawsze stosuj ograniczenia: no-pty,no-X11-forwarding,permitopen="...";
    • Organizuj infrastrukturę deklaratywnie za pomocą spójnego pliku ~/.ssh/config.
Podsumowanie części tunelowania: Slajd przedstawia zagadnienie Tunelowanie SSH w pigułce inżynierskiej w ramach tematu Podsumowanie części tunelowania na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Podsumowanie części tunelowania
39/49
Laboratorium - generowanie pary kluczy
Cel slajdu: Slajd omawia zagadnienie „Laboratorium - generowanie pary kluczy” w kontekście: Lab: generowanie kluczy SSH Ed25519.

Lab: generowanie kluczy SSH Ed25519

  • Krok 1: Otwórz terminal roboczy (Linux / macOS / PowerShell Windows).
  • Krok 2: Generowanie nowoczesnej pary kluczy kryptograficznych:
ssh-keygen -t ed25519 -a 100 -C "jan.nowak@firma.pl"
  • Szczegółowa analiza parametrów wywołania:
    • -t ed25519 – wybór algorytmu opartego na krzywej Edwardsa Curve25519;
    • -a 100 – wymuszenie 100 rund funkcji wyprowadzania klucza bcrypt KDF (drastycznie utrudnia atak brute-force na skradziony plik);
    • -C "komentarz" – etykieta ułatwiająca identyfikację klucza w plikach konfiguracyjnych.
  • Zabezpieczenie frazą szyfrującą (Passphrase):
    • Podczas monitu wprowadź silną, wielowyrazową frazę szyfrującą;
    • Pozostawienie pustej frazy jest kardynalnym błędem i oznacza przechowywanie tożsamości otwartym tekstem!
  • Wygenerowane pliki w katalogu ~/.ssh/:
    • id_ed25519 – klucz prywatny (ściśle tajny!);
    • id_ed25519.pub – klucz publiczny przeznaczony do instalacji na serwerach.
Laboratorium - generowanie pary kluczy: Slajd przedstawia zagadnienie Lab: generowanie kluczy SSH Ed25519 w ramach tematu Laboratorium - generowanie pary kluczy na przykładach poleceń oraz diagnostyki w systemach Linux, Windows i RouterOS. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Laboratorium - generowanie pary kluczy
40/49
Laboratorium - wysyłka klucza na serwer
Cel slajdu: Slajd omawia zagadnienie „Laboratorium - wysyłka klucza na serwer” w kontekście: Lab: instalacja klucza publicznego na serwerze.

Lab: instalacja klucza publicznego na serwerze

  • Metoda zalecana: użycie dedykowanego narzędzia ssh-copy-id:
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 51022 uzytkownik@serwer.firma.pl
  • Co wykonuje polecenie ssh-copy-id pod maską?
    • Automatycznie weryfikuje istnienie katalogu ~/.ssh na serwerze zdalnym;
    • Ustawia bezpieczne uprawnienia katalogu: chmod 700 ~/.ssh;
    • Dopisuje treść klucza do pliku ~/.ssh/authorized_keys (nie nadpisując istniejących wpisów);
    • Ustawia bezpieczne uprawnienia pliku: chmod 600 ~/.ssh/authorized_keys.
  • Ręczna procedura alternatywna (dla systemów bez ssh-copy-id):
cat ~/.ssh/id_ed25519.pub | ssh -p 51022 uzytkownik@serwer.firma.pl \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
  • Weryfikacja: spróbuj zalogować się ponownie – demon powinien poprosić o odblokowanie klucza prywatnego, a nie o hasło systemowe!
Laboratorium - wysyłka klucza na serwer: Slajd przedstawia zagadnienie Lab: instalacja klucza publicznego na serwerze w ramach tematu Laboratorium - wysyłka klucza na serwer na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Laboratorium - wysyłka klucza na serwer
41/49
Laboratorium - ssh-agent i passphrase
Cel slajdu: Slajd omawia zagadnienie „Laboratorium - ssh-agent i passphrase” w kontekście: Lab: agent SSH i zarządzanie kluczami w pamięci.

Lab: agent SSH i zarządzanie kluczami w pamięci

  • Krok 4: Uruchomienie demona ssh-agent:
    • Linux / macOS: eval `ssh-agent -s` (uruchamia proces agenta i eksportuje zmienne środowiskowe);
    • Windows PowerShell: uruchomienie usługi systemowej Start-Service ssh-agent.
  • Załadowanie i odblokowanie klucza prywatnego:
    ssh-add ~/.ssh/id_ed25519
    • Wprowadź frazę szyfrującą (passphrase) tylko raz;
    • Klucz prywatny zostaje zdeszyfrowany i umieszczony w chronionej pamięci RAM agenta;
    • Wszystkie kolejne połączenia SSH do autoryzowanych serwerów logują się natychmiast bez ponownego pytania o hasło.
  • Zarządzanie załadowanymi tożsamościami:
    • Wyświetlenie listy załadowanych kluczy: ssh-add -l (odciski) lub ssh-add -L (klucze publiczne);
    • Ograniczenie czasu obecności w pamięci (np. 4 godziny): ssh-add -t 4h ~/.ssh/id_ed25519;
    • Usunięcie konkretnego klucza: ssh-add -d ~/.ssh/id_ed25519; wyczyszczenie całego agenta: ssh-add -D.
Laboratorium - ssh-agent i passphrase: Slajd przedstawia zagadnienie Lab: agent SSH i zarządzanie kluczami w pamięci w ramach tematu Laboratorium - ssh-agent i passphrase na przykładach poleceń oraz diagnostyki w systemach Linux, Windows i RouterOS. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Laboratorium - ssh-agent i passphrase
42/49
Laboratorium - konfiguracja ~/.ssh/config
Cel slajdu: Slajd omawia zagadnienie „Laboratorium - konfiguracja ~/.ssh/config” w kontekście: Lab: automatyzacja połączeń w pliku ~/.ssh/config.

Lab: automatyzacja połączeń w pliku ~/.ssh/config

  • Krok 5: Utwórz lub edytuj plik konfiguracyjny ~/.ssh/config na stacji roboczej.
  • Wzorcowy wpis laboratoryjny dla serwera firmowego:
Host serwer-produkcyjny
    HostName serwer.firma.pl
    Port 51022
    User admin
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 3
    LocalForward 13306 127.0.0.1:3306
  • Weryfikacja uprawnień pliku (warunek krytyczny!):
    chmod 600 ~/.ssh/config (systemy Unix/macOS).
  • Testowanie połączenia:
    Wystarczy wpisać: ssh serwer-produkcyjny. Klient automatycznie wybierze port 51022, użytkownika admin, dedykowany klucz Ed25519 oraz zestawi tunel do portu bazy danych 3306.
Laboratorium - konfiguracja ~/.ssh/config: Slajd przedstawia zagadnienie Lab: automatyzacja połączeń w pliku ~/.ssh/config w ramach tematu Laboratorium - konfiguracja ~/.ssh/config na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Laboratorium - konfiguracja ~/.ssh/config
43/49
Laboratorium - debugowanie z flagą -v
Cel slajdu: Slajd omawia zagadnienie „Laboratorium - debugowanie z flagą -v” w kontekście: Lab: diagnostyka i analiza handshake z flagami -v.

Lab: diagnostyka i analiza handshake z flagami -v

  • Krok 6: Uruchomienie klienta SSH w trybie diagnostycznym (Verbose Mode):
ssh -v serwer-produkcyjny
ssh -vv serwer-produkcyjny    # wyższy poziom szczegółowości
ssh -vvv serwer-produkcyjny   # maksymalna diagnostyka pakietów
  • Co analizujemy w strumieniu komunikatów diagnostycznych?
    • Wymiana banerów: wersje oprogramowania klienta i serwera (np. OpenSSH_9.6);
    • KEXINIT: uzgadnianie algorytmów wymiany kluczy (kex), szyfrów i kodów MAC;
    • Host key verification: sprawdzanie odcisku serwera w known_hosts;
    • Offer publickey: prezentacja kluczy z pliku i agenta (sprawdź, czy serwer akceptuje algorytm ssh-ed25519);
    • Sukces autoryzacji: komunikat Authentication succeeded (publickey).
  • Jeśli pojawi się Permission denied (publickey), przeanalizuj, czy serwer w ogóle pytał o twój klucz i czy klucz został zaoferowany.
Laboratorium - debugowanie z flagą -v: Slajd przedstawia zagadnienie Lab: diagnostyka i analiza handshake z flagami -v w ramach tematu Laboratorium - debugowanie z flagą -v na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Laboratorium - debugowanie z flagą -v
44/49
Laboratorium - tunel Local Forwarding
Cel slajdu: Slajd omawia zagadnienie „Laboratorium - tunel Local Forwarding” w kontekście: Lab: uruchomienie i testowanie tunelu lokalnego.

Lab: uruchomienie i testowanie tunelu lokalnego

  • Krok 7: Zestawienie produkcyjnego tunelu lokalnego w tle:
ssh -L 13306:127.0.0.1:3306 -N -f admin@serwer.firma.pl -p 51022
  • Krok 8: Weryfikacja otwartego gniazda nasłuchującego na stacji roboczej:
    • Linux: ss -tlnp | grep 13306 (lub netstat -tlnp);
    • macOS: lsof -i :13306;
    • Windows PowerShell: Get-NetTCPConnection -LocalPort 13306.
  • Krok 9: Test połączenia aplikacyjnego z bazą przez tunel:
    mysql -h 127.0.0.1 -P 13306 -u dbuser -p
    (ruch jest transparentnie tunelowany i szyfrowany do serwera docelowego).
  • Krok 10: Prawidłowe zakończenie tunelu działającego w tle:
    • Identyfikacja numeru procesu: pgrep -f "ssh -L 13306";
    • Zatrzymanie procesu tunelu: pkill -f "ssh -L 13306" (lub kill PID).
Laboratorium - tunel Local Forwarding: Slajd przedstawia zagadnienie Lab: uruchomienie i testowanie tunelu lokalnego w ramach tematu Laboratorium - tunel Local Forwarding na przykładach poleceń oraz diagnostyki w systemach Linux, Windows i RouterOS. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Laboratorium - tunel Local Forwarding
45/49
Troubleshooting - prawa dostępu do plików
Cel slajdu: Slajd omawia zagadnienie „Troubleshooting - prawa dostępu do plików” w kontekście: Problemy z uprawnieniami ~/.ssh i mechanizm StrictModes.

Problemy z uprawnieniami ~/.ssh i mechanizm StrictModes

  • Klasyczny błąd bezpieczeństwa:
    Permissions 0644 for '/home/user/.ssh/id_ed25519' are too open.
    It is required that your private key files are NOT accessible by others.
  • Mechanizm StrictModes yes w demonie SSH:
    • Demon SSH odrzuca uwierzytelnianie, jeśli pliki kluczy lub katalogi posiadają prawa zapisu dla grupy lub innych użytkowników (ochrona przed wstrzyknięciem klucza przez innego lokalnego użytkownika).
  • Wzorcowa matryca uprawnień POSIX (Złoty Standard):
Ścieżka Uprawnienia Zapis symboliczny Opis
~/.ssh/ 700 drwx------ Katalog konfiguracji SSH
~/.ssh/id_ed25519 600 -rw------- Klucz prywatny (ściśle tajny)
~/.ssh/id_ed25519.pub 644 -rw-r--r-- Klucz publiczny (jawny)
~/.ssh/authorized_keys 600 -rw------- Baza zaufanych kluczy serwera
~/.ssh/config 600 -rw------- Konfiguracja klienta
Katalog domowy ~/ 755 lub 750 drwxr-xr-x Brak uprawnień zapisu dla grupy!
Troubleshooting - prawa dostępu do plików: Slajd przedstawia zagadnienie Problemy z uprawnieniami ~/.ssh i mechanizm StrictModes w ramach tematu Troubleshooting - prawa dostępu do plików na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Troubleshooting - prawa dostępu do plików
46/49
Troubleshooting - known_hosts i MITM
Cel slajdu: Slajd omawia zagadnienie „Troubleshooting - known_hosts i MITM” w kontekście: Konflikt known_hosts i ostrzeżenie o ataku Man-in-the-Middle.

Konflikt known_hosts i ostrzeżenie o ataku Man-in-the-Middle

  • Krytyczny komunikat ostrzegawczy OpenSSH:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  • Przyczyny wystąpienia ostrzeżenia:
    • Legalne: przeinstalowanie systemu operacyjnego na serwerze, wymiana sprzętu, celowa rotacja kluczy hosta przez zespół DevOps;
    • Wrogie: faktyczny atak Man-in-the-Middle (zatrucie tablicy ARP, podszycie pod adres IP serwera, manipulacja wpisami DNS).
  • Prawidłowa procedura inżynierska:
    • 1. Zweryfikuj odcisk klucza serwera w niezależnym kanale pozapasmowym (Out-of-Band);
    • 2. Po potwierdzeniu legalności usuń nieaktualny wpis za pomocą dedykowanego polecenia:
      ssh-keygen -R serwer.firma.pl (lub z portem: ssh-keygen -R "[serwer.firma.pl]:51022");
    • 3. Połącz się ponownie i zweryfikuj nowy odcisk przed zaakceptowaniem.
Troubleshooting - known_hosts i MITM: Slajd przedstawia zagadnienie Konflikt known_hosts i ostrzeżenie o ataku Man-in-the-Middle w ramach tematu Troubleshooting - known_hosts i MITM na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Troubleshooting - known_hosts i MITM
47/49
Troubleshooting - inne typowe problemy
Cel slajdu: Slajd omawia zagadnienie „Troubleshooting - inne typowe problemy” w kontekście: Inne częste awarie połączeń SSH i metody ich rozwiązywania.

Inne częste awarie połączeń SSH i metody ich rozwiązywania

  • 1. ssh: connect to host ... port 22: Connection refused:
    • Przyczyna: demon SSH nie działa, port jest błędny lub zapora sieciowa odrzuca pakiety TCP SYN (flaga RST);
    • Rozwiązanie: sprawdź status usługi sudo systemctl status sshd oraz zweryfikuj numer portu w sshd_config.
  • 2. ssh: connect to host ... port 22: Connection timed out:
    • Przyczyna: pakiety są bezgłośnie odrzucane (DROP) przez zaporę sieciową po drodze lub błędny routing w sieci;
    • Rozwiązanie: audyt reguł firewall (nftables, security groups w chmurze) oraz polecenie traceroute / mtr.
  • 3. Received disconnect: Too many authentication failures:
    • Przyczyna: lokalny ssh-agent oferuje serwerowi zbyt wiele kluczy z rzędu, przekraczając limit MaxAuthTries;
    • Rozwiązanie: dodaj w konfiguracji: IdentitiesOnly yes oraz wskaż poprawny IdentityFile.
  • 4. ssh: Could not resolve hostname ...: Name or service not known:
    • Przyczyna: awaria resolvera DNS; sprawdź konfigurację w /etc/resolv.conf lub użyj adresu IP.
  • Zaawansowana inspekcja po stronie serwera: sudo journalctl -u ssh -f lub /var/log/auth.log.
Troubleshooting - inne typowe problemy: Slajd przedstawia zagadnienie Inne częste awarie połączeń SSH i metody ich rozwiązywania w ramach tematu Troubleshooting - inne typowe problemy na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Troubleshooting - inne typowe problemy
48/49
Cheat Sheet - najważniejsze komendy SSH
Cel slajdu: Slajd omawia zagadnienie „Cheat Sheet - najważniejsze komendy SSH” w kontekście: Ściągawka poleceń SSH dla administratora.

Ściągawka poleceń SSH dla administratora

  • Generowanie pary kluczy Ed25519 z funkcją bcrypt KDF:
    ssh-keygen -t ed25519 -a 100 -C "admin@firma.pl"
  • Instalacja klucza publicznego na serwerze z niestandardowym portem:
    ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 51022 admin@serwer.pl
  • Logowanie przez bastion (serwer przesiadkowy):
    ssh -J admin@bastion.firma.pl:51022 dbuser@10.0.2.50
  • Tunel lokalny w tle (dostęp do odizolowanej bazy danych):
    ssh -L 13306:127.0.0.1:3306 -N -f admin@serwer.pl -p 51022
  • Tunel zdalny (udostępnienie lokalnej usługi zza podwójnego NAT-u):
    ssh -R 8080:127.0.0.1:80 -N -f admin@publiczny-vps.pl
  • Dynamiczne proxy SOCKS5 (bezpieczny Internet w publicznym Wi-Fi):
    ssh -D 1080 -N -f admin@serwer.pl
  • Pełna diagnostyka połączenia (maksymalny poziom debugowania):
    ssh -vvv admin@serwer.pl -p 51022
  • Bezpieczne usunięcie nieaktualnego klucza hosta z bazy:
    ssh-keygen -R "[serwer.pl]:51022"
  • Weryfikacja składni pliku konfiguracyjnego demona przed restartem:
    sudo sshd -t
Cheat Sheet - najważniejsze komendy SSH: Slajd przedstawia zagadnienie Ściągawka poleceń SSH dla administratora w ramach tematu Cheat Sheet - najważniejsze komendy SSH na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Cheat Sheet - najważniejsze komendy SSH
49/49
Zakończenie - podsumowanie i pytania
Cel slajdu: Slajd omawia zagadnienie „Zakończenie - podsumowanie i pytania” w kontekście: Podsumowanie wiedzy o protokole i narzędziach SSH.

Podsumowanie wiedzy o protokole i narzędziach SSH

  • Trzy filary nowoczesnego i bezpiecznego zdalnego dostępu:
    • 1. Silna kryptografia hybrydowa: dominacja algorytmu Ed25519 (krzywe Edwardsa), efemeryczna wymiana kluczy ECDH (Curve25519 z właściwością PFS), nowoczesne szyfry AEAD (ChaCha20-Poly1305, AES-GCM) oraz eliminacja przestarzałych standardów (SHA-1, 3DES, CBC);
    • 2. Bezwzględny hardening demona OpenSSH: całkowite wyłączenie logowania hasłem (PasswordAuthentication no), blokada bezpośredniego dostępu konta root, autoryzacja grupowa (AllowGroups), zmiana portu oraz limity sesji;
    • 3. Wszechstronność tunelowania: zaawansowany routing usług (Local, Remote, Dynamic SOCKS5) oraz architektury strefowe oparte na bastionach (ProxyJump).
  • Najważniejsze nawyki inżynierskie:
    • Zawsze chroń klucz prywatny silną frazą szyfrującą i prawami chmod 600;
    • Przed przeładowaniem demona zawsze wykonaj test składni sshd -t;
    • Weryfikuj odciski palców serwerów przed zatwierdzeniem pierwszego połączenia.
  • Dziękuję za uwagę! Zapraszam do pytań i dyskusji.
Zakończenie - podsumowanie i pytania: Slajd przedstawia zagadnienie Podsumowanie wiedzy o protokole i narzędziach SSH w ramach tematu Zakończenie - podsumowanie i pytania na przykładach konfiguracji i diagnostyki w systemie Linux. Architekturę protokołu, wymianę kluczy i warstwę połączenia opisano w RFC 4251 i RFC 4253, a referencyjną implementację stanowi OpenSSH.
Zakończenie - podsumowanie i pytania