SSH – polecenia, opcje, tunele i praktyczne przykłady

Bezpieczna administracja zdalna – protokół, opcje, tunele

SSH

Prezentacja obejmuje protokół SSH od podstaw – od instalacji i konfiguracji, przez szczegółowy opis wszystkich opcji klienta, po zaawansowane techniki tunelowania (-L, -R, -D), ProxyJump (-J), uwierzytelnianie kluczami, bezpieczeństwo i dobre praktyki.

Każdy mechanizm jest ilustrowany diagramami ASCII i rzeczywistymi przykładami.

Szczególny nacisk położono na tunelowanie SSH – trzy rodzaje przekazywania portów (lokalne, zdalne, dynamiczne) z dokładnym opisem przepływu danych, zastosowaniami i konfiguracją krok po kroku.

SSH

Jego znajomość jest niezbędna nie tylko dla administratorów systemów, ale także dla inżynierów sieciowych, programistów i specjalistów DevOps.

Prezentacja została zaprojektowana jako praktyczne kompendium wiedzy – od pierwszego połączenia po zaawansowane tunele wykorzystywane w środowiskach produkcyjnych.

Materiał jest podzielony na bloki: wprowadzenie i instalacja (slajdy 1-7), uwierzytelnianie (8-10), połączenia sieciowe (11-13), tunelowanie – najważniejsza część (14-19), narzędzia pokrewne (20-21), bezpieczeństwo i konfiguracja (22-23).

Każdy blok zawiera przykłady i diagramy ułatwiające zrozumienie.

Do prezentacji dołączono rozszerzone opisy (kliknij "Pokaż rozszerzenie"), które zawierają dodatkowe szczegóły techniczne, historię protokołu oraz zaawansowane techniki konfiguracyjne dla doświadczonych administratorów.

SSH Secure Shell

Domyślnie na porcie TCP 22.

Kluczowe funkcje: zdalny terminal, tunelowanie dowolnych protokołów, bezpieczny transfer plików (SFTP/SCP), przekazywanie X11 i agenta uwierzytelniającego.

Prezentacja szczegółowo omawia opcje klienta: -p (port), -i (klucz), -L/-R/-D (tunele), -J (ProxyJump), -C (kompresja), -v (verbose), -N (tylko tunel), -f (tło), -t (TTY), -A (agent forwarding).

Każda opcja jest zilustrowana przykładem i diagramem.

Główna część poświęcona jest tunelowaniu SSH – trzem typom przekazywania portów z rzeczywistymi zastosowaniami: bezpieczny dostęp do baz danych, ominięcie firewalla, proxy SOCKS5 dla przeglądarki, tunelowanie VNC, RDP i innych protokołów.

Obraz: mapa myśli SSH – opcje, tunele, bezpieczeństwo

Protokół SSH składa się z trzech warstw: transportowej (negocjacja szyfrowania, uwierzytelnianie hosta), uwierzytelniania (użytkownika) i połączenia (multipleksacja kanałów).

Dzięki temu pojedyncze połączenie SSH może jednocześnie obsługiwać sesję terminalową, tunel X11, przekierowanie portów i transfer SFTP.

OpenSSH, rozwijany przez projekt OpenBSD, jest standardem de facto.

Wersja 9.x wprowadziła istotne ulepszenia: domyślnie szyfrowanie ChaCha20-Poly1305, wyłączenie starszych algorytmów (ssh-rsa, diffie-hellman-group14-sha1) oraz zabezpieczenia przed atakami na łańcuch kluczy w ProxyJump.

Źródła wiedzy o SSH

SSH Mastery – Michael W. Lucas, Tilted Windmill Press (najlepsza książka o SSH)
OpenSSH Cookbook – dokumentacja online, www.openssh.com
Linux. Biblia administratora – Evi Nemeth i in., wyd. Helion
Strony manual: man ssh, man sshd_config, man ssh_config, man ssh-keygen
RFC 4251–4254 – specyfikacja protokołu SSH
Practical TCP/IP – Niall Mansfield (rozdział o tunelowaniu SSH)

Michael W. Lucas, autor SSH Mastery, jest uznanym ekspertem w dziedzinie administracji systemami.

Jego książka obejmuje zarówno podstawy, jak i zaawansowane techniki – certyfikaty, tunele, ProxyJump, uwierzytelnianie wieloskładnikowe.

Strony man (manual) OpenSSH są kompletne i zawsze aktualne – każda opcja ma dokładny opis składni i działania.

Znajomość RFC jest przydatna przy diagnostyce problemów kompatybilności między implementacjami (OpenSSH, Dropbear, PuTTY, Cisco).

sudo apt update && sudo apt install openssh-server -y

sudo systemctl status ssh

Weryfikacja nasłuchiwania:

sudo ss -tlnp | grep :22
# Wynik: LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,...))

Pliki konfiguracyjne: /etc/ssh/sshd_config (serwer), /etc/ssh/ssh_config (klient systemowy), ~/.ssh/config (klient użytkownika). Klucze hosta w /etc/ssh/ssh_host_*.

Sprawdzenie statusu:

Przez firewall UFW: sudo ufw allow ssh.

Jeśli nieaktywny: sudo systemctl enable --now ssh.

Instalacja serwera SSH jest prosta – jeden pakiet. Po instalacji serwer uruchamia się automatycznie.

Obraz: zrzut terminala z instalacją openssh-server

Jeśli UFW jest aktywny: sudo ufw allow ssh lub sudo ufw allow 22/tcp.

Test lokalny: ssh localhost lub 127.0.0.1.

W Debianie pakiet openssh-server instaluje demona sshd wraz z domyślną konfiguracją.

Katalog /etc/ zawiera: sshd_config (konfiguracja serwera), ssh_config (domyślna konfiguracja klienta), ssh_host_rsa_key, ssh_host_ecdsa_key, ssh_host_ed25519_key (klucze hosta).

W Ubuntu z UFW przed instalacją warto sprawdzić: sudo ufw status.

W Debianie domyślnie nie ma restrykcyjnych reguł firewalla, ale w środowisku produkcyjnym warto sprawdzić iptables/nftables.

Przy pierwszym połączeniu pojawi się ostrzeżenie o nieznanym kluczu hosta – zaakceptuj.

Połączenie powinno działać z logowaniem hasłem bieżącego użytkownika.

Sprawdzenie procesu sshd:

ps aux | grep sshd
# root  ... /usr/sbin/sshd -D  (proces główny)
# root ... sshd: user [priv] (proces dla sesji)

Sprawdzenie portu nasłuchu:

sudo ss -tlnp | grep ssh
# LISTEN 0 128  0.0.0.0:22  0.0.0.0:*  users:(("sshd",pid=1234,fd=3))
# LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1234,fd=4))

Test lokalny i zdalny:

ssh localhost  # test lokalny
ssh 192.168.1.100  # test zdalny (adres serwera)
ssh -p 2222 user@192.168.1.100 # test na niestandardowym porcie

Weryfikacja odcisku klucza hosta:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
# 256 SHA256:xYZabc... user@host (ED25519)

Proces sshd działa jako demon systemowy.

Główny proces nasłuchuje na porcie 22.

Przy każdym połączeniu sshd forkuje nowy proces dla sesji.

Polecenie ss -tlnp | grep ssh wyświetla gniazda nasłuchujące.

Polecenie ps aux | grep sshd pokazuje: proces rodzica (sshd -D) i procesy potomne dla aktywnych sesji.

Kolumna 0.0.0.0:22 oznacza nasłuch na wszystkich interfejsach IPv4, [::]:22 – nasłuch na wszystkich interfejsach IPv6.

Jeśli widzisz tylko [::]:22 bez 0.0.0.0:22, sprawdź opcję AddressFamily w sshd_config.

Odcisk klucza hosta (fingerprint) jest kluczowy dla bezpieczeństwa – przy pierwszym połączeniu klient SSH wyświetla odcisk i pyta o akceptację.

Zawsze porównaj go z odciskiem wygenerowanym na serwerze (ssh-keygen -lf).

Atak MITM może podmienić klucz hosta, dlatego weryfikacja odcisku przed pierwszym połączeniem jest krytyczna.

Opcja	Domyślnie	Opis
`Port`	22	Port nasłuchu. Zmiana na >1024 ogranicza skanowanie
`PermitRootLogin`	prohibit-password	Root może logować się tylko kluczem (bez hasła)
`PasswordAuthentication`	yes	Logowanie hasłem – wyłącz po wdrożeniu kluczy
`PubkeyAuthentication`	yes	Uwierzytelnianie kluczem publicznym
`MaxAuthTries`	6	Maksymalna liczba prób logowania
`AllowUsers`	(brak)	Lista dozwolonych użytkowników (spacja)
`AllowGroups`	(brak)	Lista dozwolonych grup
`ClientAliveInterval`	0	Sekundy między keepalive (0 = wyłączone)
`ClientAliveCountMax`	3	Liczba keepalive bez odpowiedzi = rozłączenie
`X11Forwarding`	yes	Przekazywanie X11 przez SSH
`AllowTcpForwarding`	yes	Zezwolenie na tunelowanie TCP

Zalecana minimalna konfiguracja: Port 2222, PermitRootLogin no, PasswordAuthentication no (po kluczach), MaxAuthTries 3, AllowUsers jan adam.

Każda opcja ma domyślną wartość.

Po zmianie: sudo systemctl restart ssh.

Główna konfiguracja serwera: /etc/ssh/sshd_config.

Obraz: zrzut pliku sshd_config z oznaczeniami

Zmiana portu z 22 na wyższy (np.

2222, 22222) ogranicza liczbę automatycznych ataków.

Wiele skryptów i botów skanuje domyślny port 22.

Przydatne na serwerach z wieloma kontami systemowymi.

AllowGroups działa analogicznie dla grup.

Uwaga: przy zmianie portu trzeba zaktualizować reguły firewalla i poinformować użytkowników.

PermitRootLogin prohibit-password zezwala rootowi na logowanie tylko z kluczem (bez hasła).

Bezpieczniej: PermitRootLogin no i logowanie na zwykłego użytkownika + sudo.

AllowUsers ogranicza listę użytkowników mogących logować się przez SSH.

ClientAliveInterval i ClientAliveCountMax zapobiegają wiszącym połączeniom – serwer wysyła keepalive co N sekund, po M brakujących odpowiedziach zamyka połączenie.

AllowTcpForwarding no wyłącza możliwość tunelowania – przydatne na serwerach, które mają być wyłącznie terminalowe.

X11Forwarding no wyłącza przekazywanie X11 – zalecane, chyba że potrzebujesz zdalnych aplikacji graficznych.

sudo sshd -t
# Brak wyniku = składnia poprawna
# Błąd: /etc/ssh/sshd_config line X: Bad configuration option

ssh -vvv localhost
# debug1: Reading configuration data /etc/ssh/ssh_config
# debug1: /etc/ssh/ssh_config line 20: Applying options for *
# debug1: Connecting to localhost [::1] port 22.
# debug1: Connection established.
# debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2
# debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1
# debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
# debug1: Authentication succeeded (publickey).

sudo journalctl -u ssh -n 20 --no-pager
sudo tail -f /var/log/auth.log | grep ssh

Po zmianie konfiguracji w sshd_config sprawdź poprawność składni przed restartem.

Test z verbose, aby zobaczyć szczegóły logowania.

Błędy logowania SSH są zapisywane w logach systemowych.

Obraz: zrzut terminala z sshd -t i ssh -vvv

Użyj journalctl -u ssh -f do monitorowania na bieżąco.

W systemach z systemd logi SSH są dostępne przez journalctl.

Polecenie sudo sshd -t testuje składnię sshd_config bez restartowania usługi.

Jest to najlepsza praktyka przed każdym restartem – błąd składni może uniemożliwić uruchomienie sshd, a w efekcie stracić zdalny dostęp do serwera.

Zawsze testuj konfigurację lokalnie (przez ssh localhost) przed rozłączeniem istniejącej sesji.

W systemach bez systemd logi są w /var/log/auth.log (Debian) lub /var/log/secure (RHEL).

Nieudane próby logowania SSH są rejestrowane z adresem IP, nazwą użytkownika i protokołem.

Opcja -vvv (lub -v, -vv) zwiększa szczegółowość komunikatów debugowania klienta.

Jest nieoceniona przy diagnostyce problemów: odrzucenie klucza, problemy z konfiguracją, błędy, problemy z tunelowaniem.

Poziomy: -v (informacje ogólne), -vv (szczegółowe negocjacje), -vvv (wszystkie dane diagnostyczne łącznie z kluczami).

# Logowanie hasłem (interaktywne)
ssh jan@192.168.1.100
# jan@192.168.1.100's password: 

# Logowanie kluczem (bez hasła – po konfiguracji)
ssh -i ~/.ssh/id_ed25519 jan@192.168.1.100

Cecha	Hasło	Klucz
Bezpieczeństwo	Niskie (brute-force, phishing)	Wysokie (kryptografia asymetryczna)
Automatyzacja	Niemożliwa	Możliwa (skrypty, Ansible)
Wygoda	Niska (za każdym razem)	Wysoka (raz skonfigurowane)
Ryzyko	Przechwycenie, zgadnięcie	Kradzież pliku klucza (zabezpiecz passphrase)

Wymaga interakcji użytkownika.

Podatne na ataki brute-force.

Uwierzytelnianie hasłem: klient wysyła hasło przez szyfrowany kanał.

Uwierzytelnianie kluczem publicznym: klient generuje parę kluczy (prywatny i publiczny).

Klucz publiczny trafia na serwer do ~/.ssh/authorized_keys.

Podczas logowania SSH klient udowadnia posiadanie klucza prywatnego bez przesyłania go przez sieć.

Obraz: diagram porównawczy hasło vs klucz

Klient musi odszyfrować je kluczem prywatnym i odesłać.

Tylko posiadacz klucza prywatnego może tego dokonać.

Klucz prywatny nigdy nie opuszcza komputera klienta.

Klucz prywatny powinien być chroniony hasłem (passphrase).

Uwierzytelnianie kluczem publicznym działa na zasadzie wyzwanie-odpowiedź: serwer szyfruje losowe dane kluczem publicznym użytkownika i wysyła do klienta.

Bez passphrase – każdy kto zdobędzie plik klucza, ma dostęp do serwera.

Z passphrase – nawet przy kradzieży pliku, atakujący musi znać hasło.

Agent SSH (ssh-agent) przechowuje odblokowane klucze w pamięci na czas sesji, eliminując konieczność wielokrotnego wpisywania passphrase.

Ataki brute-force na SSH są powszechne – boty skanują Internet w poszukiwaniu serwerów z domyślnym portem 22 i słabymi hasłami.

Po wdrożeniu kluczy należy ustawić PasswordAuthentication no w sshd_config, co całkowicie eliminuje ataki brute-force na hasła.

ssh-keygen -t ed25519 -C "jan@laptop-2026"
# Generating public/private ed25519 key pair.
# Enter file in which to save the key (~/.ssh/id_ed25519):
# Enter passphrase (empty for no passphrase):
# Enter same passphrase again:
# Your identification has been saved in ~/.ssh/id_ed25519
# Your public key has been saved in ~/.ssh/id_ed25519.pub

Porównanie algorytmów kluczy SSH:

Algorytm	Długość klucza	Bezpieczeństwo	Szybkość
Ed25519	256 bitów	Bardzo wysokie	Bardzo szybki
RSA	3072–4096 bitów	Wysokie	Wolniejszy
ECDSA (P-256)	256 bitów	Wysokie (zastrzeżenia NSA)	Szybki
DSA	1024 bity	Niskie (przestarzałe)	Wolny

Rekomendacja: ssh-keygen -t ed25519 -C "twoj@email". Klucz Ed25519 jest bezpieczniejszy i szybszy od RSA 4096.

Rekomendowany algorytm: Ed25519.

Generowanie pary kluczy odbywa się poleceniem ssh-keygen.

Domyślnie komentarz to user@hostname.

Zaleca się opisowy komentarz, np.

"jan@laptop-prywatny" lub "klucz-do-serwera-produkcyjnego".

Passphrase to dodatkowe hasło chroniące klucz prywatny.

Flaga -C (comment) dodaje komentarz do klucza publicznego – przydatne przy wielu kluczach.

Jeśli nie podasz passphrase, klucz jest zapisany w czystym tekście – każdy, kto ma dostęp do pliku, ma dostęp do wszystkich serwerów skonfigurowanych z tym kluczem.

Z passphrase użyj ssh-agent, aby odblokować klucz raz na sesję.

Po wygenerowaniu kluczy znajdziesz: ~/.ssh/id_ed25519 (klucz prywatny – NIGDY nie udostępniaj), ~/.ssh/id_ed25519.pub (klucz publiczny – możesz kopiować na serwery).

Uprawnienia: klucz prywatny 600, klucz publiczny 644, katalog ~/.ssh 700.

ssh-copy-id -p 2222 jan@192.168.1.100
# /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "..."
# /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s)
# Number of key(s) added: 1
# Now try logging into the machine, with: "ssh -p 2222 jan@192.168.1.100"

cat ~/.ssh/id_ed25519.pub | ssh jan@192.168.1.100 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

# ssh-ed25519 AAAAC3... komentarz1
# ssh-rsa AAAAB3... komentarz2

Po wdrożeniu kluczy: w sshd_config ustaw PasswordAuthentication no i restart serwera. Od tej pory tylko klucze są akceptowane.

Najprostszy sposób: ssh-copy-id – automatycznie kopiuje klucz publiczny i ustawia odpowiednie uprawnienia.

Ręczne kopiowanie (gdy ssh-copy-id niedostępny, np. Windows):

Struktura pliku ~/.ssh/authorized_keys na serwerze (jeden klucz na linię):

Obraz: diagram kopiowania klucza z klienta na serwer

Flaga -i pozwala wskazać konkretny klucz: ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host.

Plik authorized_keys może zawierać opcje ograniczające dla konkretnych kluczy: from="192.168.1.*" (tylko z danej sieci), command="/usr/bin/rsync" (tylko konkretne polecenie), no-pty (bez terminala), no-agent-forwarding, no-X11-forwarding.

Przykład: from="10.0.0.0/8",command="/usr/bin/rsync --server" - AAA... komentarz.

Po skopiowaniu kluczy i wyłączeniu PasswordAuthentication ataki brute-force przestają działać.

Atakujący musiałby posiadać plik klucza prywatnego, co jest znacznie trudniejsze niż zgadnięcie hasła.

Dodatkowo fail2ban blokuje IP po N próbach nawet dla uwierzytelniania kluczem.

  Klient:50001 ───── SYN ────► Serwer:22
  Klient:50001 ◄── SYN+ACK ─── Serwer:22
  Klient:50001 ───── ACK ────► Serwer:22

Standardowe porty protokołów:

Port	Protokół	Opis
22	SSH	Secure Shell – zdalny terminal
23	Telnet	Niezaszyfrowany terminal (nie używać!)
80	HTTP	Strony WWW
443	HTTPS	Szyfrowane WWW
3306	MySQL	Baza danych MySQL/MariaDB
5900	VNC	Zdalny pulpit graficzny

Każde połączenie TCP identyfikowane jest przez parę (adres IP, port) dla obu stron.

Serwer SSH nasłuchuje na gnieździe 0.0.0.0:22.

Klient łączy się z gniazdem adres_serwera:22.

Sprawdzenie otwartych portów na serwerze: sudo ss -tlnp (lokalnie) lub nmap -p 22 192.168.1.100 (zdalnie).

Obraz: schemat trzech kroków handshake TCP

Każde połączenie SSH ma unikalną czwórkę.

Gniazdo (socket) definiuje czwórka: adres IP źródła, port źródłowy, adres IP celu, port docelowy.

Dwa różne połączenia muszą różnić się co najmniej jednym elementem.

Port źródłowy jest przydzielany losowo z puli (zakres 32768–60999 w Linuxie).

Polecenie nmap jest standardowym skanerem portów.

Użycie: nmap -sS -p 22 192.168.1.100 (skanowanie SYN stealth).

Wynik: open (port otwarty), closed (odrzucone połączenie), filtered (blokowane przez firewall).

Jeśli nmap nie jest zainstalowany: apt install nmap lub użyj netcat: nc -zv 192.168.1.100 22.

Zmiana domyślnego portu SSH na wyższy (np. 2222) utrudnia automatyczne skanowanie, ale nie jest realnym zabezpieczeniem przed ukierunkowanym atakiem.

Prawdziwe zabezpieczenie to uwierzytelnianie kluczami i fail2ban.

  Klient (10.0.0.2)  Serwer (10.0.0.5)
  ┌────────────────┐  ┌────────────────┐
  │  ssh client  │───────│  sshd server  │
  │  port 50001  │  LAN  │  port 22  │
  └────────────────┘  ──►  └────────────────┘
  |  |
  ┌───┴───┐  ┌───┴───┐
  │ Switch│  │Switch │
  └───────┘  └───────┘
  |  |
  ┌───┴────────────────────────┴───┐
  │  Kabel Ethernet  │
  └────────────────────────────────┘

Polecenie: ssh jan@10.0.0.5

Diagnostyka przed SSH:

ping -c 3 10.0.0.5  # test łączności ICMP
telnet 10.0.0.5 22  # test portu TCP 22
nmap -p 22 10.0.0.5 # skanowanie portu

W sieci LAN komputery komunikują się bezpośrednio.

Serwer SSH na 10.0.0.5, klient na 10.0.0.2 – brak routerów.

Obraz: schemat dwóch komputerów w LAN z przełącznikiem

W laboratorium zaleca się adresy statyczne dla serwerów.

W sieci LAN komunikacja SSH jest bezpośrednia – jedynym wymaganiem jest poprawne adresowanie IP i dostępność serwera na porcie 22.

Jeśli ping działa (ICMP Echo Reply), ale SSH nie odpowiada: sprawdź na serwerze sudo ss -tlnp | grep :22 (czy sshd nasłuchuje) i sudo ufw status (czy firewall nie blokuje).

Telnet do portu 22 to szybki test: jeśli port jest otwarty, zobaczysz banner (SSH-2.0-OpenSSH_9.2p1 Debian-2).

Jeśli połączenie zostaje odrzucone (Connection refused) – sshd nie nasłuchuje lub firewall blokuje.

Jeśli nie ma odpowiedzi (timeout) – firewall odrzuca pakiety bez odpowiedzi.

Jeśli serwer ma adres z DHCP, adres może się zmienić po restarcie.

Użyj statycznego adresu IP w konfiguracji sieci lub skonfiguruj rezerwację DHCP na routerze.

  Host (192.168.1.10)  VirtualBox NAT  VM (10.0.2.15)
  ┌────────────────┐  ┌──────────────┐  ┌────────────────┐
  │ ssh -p 2222  │───►│  :2222→:22  │───►│ sshd:22  │
  │ user@127.0.0.1 │  │  forward  │  │ 10.0.2.15  │
  └────────────────┘  └──────────────┘  └────────────────┘
  |  |  |
  TCP/2222 → localhost  NAT engine  VM internal
  (host:2222 → VM:22)  (masquerade)  (10.0.2.15:22)

CLI (VBoxManage):

VBoxManage modifyvm "NazwaVM" --natpf1 "SSH,tcp,,2222,,22"

ssh -p 2222 jan@127.0.0.1

Rozwiązanie: przekierowanie portów.

Konfiguracja przekierowania w VirtualBox:

Alternatywa: tryb mostkowy (bridged) – VM ma własny adres w LAN hosta, połączenie bezpośrednie: ssh jan@192.168.1.150.

Maszyna wirtualna za NAT-em ma adres wewnętrzny (10.0.2.x), niedostępny bezpośrednio z sieci hosta.

GUI: Ustawienia VM → Sieć → Adapter → Zaawansowane → Przekierowanie portów

Po konfiguracji łączymy się przez localhost:

Obraz: schemat NAT z port forwarding w VirtualBox

Reguła NAT w VBoxManage: --natpf1 oznacza pierwszy adapter NAT (natpf1, natpf2, ...).

Format: "nazwa,protokół,ip_hosta,port_hosta,ip_vm,port_vm".

Jeśli pominiemy ip_hosta, reguła działa na wszystkich interfejsach hosta.

Można dodać wiele reguł dla różnych usług (SSH, HTTP, RDP).

W Hyper-V przez PowerShell: New-NetNatStaticMapping.

Tryb NAT w VirtualBox/VMware tworzy wirtualny router, który tłumaczy adresy VM (10.0.2.0/24) na adres hosta (192.168.1.x).

VM ma dostęp do Internetu przez NAT, ale z zewnątrz jest niewidoczna.

Port forwarding mapuje port na hoście na port w VM, umożliwiając dostęp do usług w VM.

W VMware Workstation konfiguracja NAT: Edytor sieci wirtualnych (Virtual Network Editor) → Ustawienia NAT → Przekierowanie portów.

W produkcji zamiast NAT używa się mostkowania z firewallem na VM lub sieci z izolacją VLAN.

Zastosowania tuneli SSH:

Bezpieczny dostęp do baz danych (MySQL, PostgreSQL) bez konieczności otwierania portu na firewallu
Korzystanie z usług w sieci firmowej przez publiczny Internet (VNC, RDP, HTTP)
Proxy SOCKS5 do anonimowego przeglądania Internetu przez serwer SSH
Ominięcie firewalla blokującego określone porty
Szyfrowanie niezaszyfrowanych protokołów (HTTP, VNC, POP3, IMAP)

Koncepcja: SSH tworzy "rurę" (tunel) między dwoma punktami. Ruch wchodzący do rury jest szyfrowany, przesyłany przez SSH i odszyfrowywany po drugiej stronie. Aplikacja nie wie, że korzysta z tunelu.

Tunelowanie (port forwarding) umożliwia przekazywanie ruchu dowolnego protokołu TCP przez szyfrowany kanał.

To jedna z najpotężniejszych funkcji – pozwala bezpiecznie łączyć się z usługami za firewallem, omijać blokady sieciowe i szyfrować protokoły, które same nie mają szyfrowania.

Obraz: koncepcyjny diagram tunelu SSH – klient, tunel, serwer, usługa

Protokół SSH tuneluje wyłącznie protokół TCP.

SSH nie ma wbudowanego mechanizmu auto-reconnect.

Protokoły UDP (DNS, VoIP, gry) nie mogą być tunelowane bezpośrednio przez standardowe -L/-R/-D.

Do tunelowania UDP przez SSH użyj dodatkowych narzędzi: netcat (nc -u), socat lub VPN (OpenVPN, WireGuard) działającego przez tunel SSH.

Architektura tunelu: klient SSH otwiera port nasłuchu na lokalnej maszynie (-L) lub na zdalnym serwerze (-R).

Każde połączenie na ten port jest przekazywane przez szyfrowany kanał SSH do docelowego hosta i portu.

Dla aplikacji wygląda to jak połączenie lokalne – nie ma świadomości istnienia tunelu ani szyfrowania.

Dla tuneli działających długo (tygodnie, miesiące) warto użyć autossh – narzędzia, które monitoruje połączenie SSH i automatycznie je restartuje po przerwaniu.

  Klient  Serwer SSH  Cel (np. DB)
  ┌──────────────────┐  ┌──────────────────┐  ┌────────────────┐
  │ Aplikacja  │  │ sshd  │  │ mysql:3306  │
  │ (np. mysql -h  │  │ 192.168.1.100  │  │ localhost  │
  │  127.0.0.1 -P  │  │  │  │ (widziany z  │
  │  3307)  │  │  │  │  serwera)  │
  └────────┬─────────┘  └────────┬─────────┘  └───────┬────────┘
  │  │  │
  localhost:3307  tunel SSH  3306
  ──────────►──────────── szyfrowany ────────────►─────────

Przykład 1: Tunel do MySQL na serwerze

ssh -fNL 3307:localhost:3306 jan@192.168.1.100
# Teraz: mysql -h 127.0.0.1 -P 3307 -u root -p
# Łączy się z MySQL na serwerze 192.168.1.100 przez tunel SSH

ssh -L 8080:10.0.1.50:80 jan@brama.example.com
# Teraz przeglądarka http://localhost:8080 = http://10.0.1.50:80

Składnia: ssh -L [bind_addr:]local_port:target_host:target_port user@ssh_server

Klient SSH otwiera port na lokalnej maszynie.

Ruch na ten port jest przekazywany przez tunel do target_host:target_port widzianego z serwera SSH.

Przykład 2: Dostęp do strony WWW za firewallem

Obraz: szczegółowy diagram przepływu danych w -L

Ważne: TARGET_HOST jest rozwiązywany z perspektywy serwera, nie klienta.

Flaga -f (background) wysyła SSH do tła po uwierzytelnieniu.

Przekazywanie lokalne (-L) to najczęściej używany typ tunelu.

Działa następująco: klient SSH otwiera gniazdo nasłuchujące na localhost:LOCAL_PORT.

Gdy aplikacja (np. klient MySQL) łączy się z localhost:LOCAL_PORT, klient SSH przejmuje połączenie i przesyła je przez szyfrowany kanał do serwera SSH.

Serwer SSH nawiązuje nowe połączenie SSH do TARGET_HOST:TARGET_PORT i przekazuje dane w obie strony.

Jeśli serwer SSH i baza danych działają na tej samej maszynie, target_host to localhost.

Jeśli baza danych jest na innym hoście w sieci wewnętrznej serwera, podaj jej adres wewnętrzny.

Flaga -N (no shell) zapobiega uruchomieniu zdalnego shella – tunel działa bez sesji terminalowej. Łącznie: -fNL port:host:port user@server to standardowa formuła dla tuneli produkcyjnych.

  Klient (z usługą)  Serwer SSH (publiczny)  Zdalny klient
  ┌──────────────────┐  ┌──────────────────┐  ┌────────────────┐
  │ Serwer HTTP:80  │  │ sshd  │  │ przeglądarka  │
  │ localhost  │◄────│ 192.168.1.100  │◄────│ http://server  │
  │ (widziany z  │  │ :8080 → tunel  │  │ .example.com  │
  │  klienta SSH)  │  │  │  │ :8080  │
  └────────┬─────────┘  └────────┬─────────┘  └───────┬────────┘
  │  │  │
  80  :8080  remote klient
  ◄─────────── szyfrowany ◄───────────

ssh -R 8080:localhost:80 jan@serwer-publiczny.pl
# Ktoś łączy się z http://serwer-publiczny.pl:8080
# Ruch trafia tunelem do localhost:80 na twoim komputerze

ssh -R 2222:localhost:22 jan@serwer-publiczny.pl
# Zdalnie: ssh -p 2222 jan@serwer-publiczny.pl
# = lokalny SSH na twoim komputerze (za NAT-em)

Składnia: ssh -R [bind_addr:]remote_port:target_host:target_port user@ssh_server

Odwrotność -L: serwer SSH otwiera port na zdalnej maszynie.

Ruch na ten port jest przekazywany przez tunel do target_host:target_port widzianego z klienta.

Przykład 1: Udostępnienie lokalnego serwera WWW

Przykład 2: Zdalny dostęp do lokalnego SSH

Obraz: diagram przepływu danych w -R (reverse tunnel)

Kolega otwiera http://vps:8080 i widzi twój lokalny serwer.

Zabezpiecz firewallem lub uwierzytelnianiem.

Uwaga: to udostępnia tunel wszystkim – bez uwierzytelniania.

Przekazywanie zdalne (-R) jest szczególnie przydatne, gdy twój komputer jest za NAT-em lub firewallem i nie ma publicznego adresu IP.

Inicjujesz połączenie SSH z serwerem publicznym, a serwer otwiera port na swojej stronie.

Każdy, kto łączy się z serwerem na tym porcie, trafia tunelem do twojego komputera.

Przykład użycia: pracujesz zdalnie na laptopie za domowym NAT-em.

Chcesz udostępnić lokalny serwer deweloperski (port 3000) koledze. Łączysz się z serwerem VPS: ssh -R 8080:localhost:3000 user@vps.

Ograniczenia: domyślnie -R nasłuchuje tylko na localhost serwera.

Aby nasłuchiwać na wszystkich interfejsach (0.0.0.0), dodaj GatewayPorts yes w sshd_config na serwerze lub użyj -R 0.0.0.0:8080:localhost:80.

  Klient  Serwer SSH  Internet
  ┌──────────────────┐  ┌──────────────────┐  ┌────────────────┐
  │ Przeglądarka  │  │ sshd  │  │ google.com  │
  │ proxy SOCKS5  │────►│ 192.168.1.100  │────►│ wikipedia.org  │
  │ 127.0.0.1:1080  │  │ wysyła żądania  │  │ ...  │
  └────────┬─────────┘  │ do docelowych  │  └────────────────┘
  │  │ serwerów  │
  localhost:1080  └──────────────────┘
  (SOCKS5 proxy)
  │  │
  Żądania HTTP/HTTPS  szyfrowany tunel
  kierowane przez proxy ──►  ─────────────►

Konfiguracja przeglądarki Firefox:

ssh -D 1080 -fN jan@192.168.1.100

Tworzy lokalny serwer proxy SOCKS5.

Składnia: ssh -D [bind_addr:]local_port user@ssh_server

Aplikacje (przeglądarka, klient poczty) kierują ruch przez to proxy, a SSH tuneluje go do serwera, który wysyła żądania do docelowych serwerów.

Ruch jest szyfrowany na odcinku klient → serwer.

Ustawienia → Sieć → Proxy → Ręczna konfiguracja proxy: SOCKS5 host: 127.0.0.1, port: 1080, zaznacz "Proxy DNS przez SOCKS5".

Zaznaczenie "Proxy DNS przez SOCKS5" jest kluczowe dla prywatności: bez tego zapytania DNS są wysyłane przez lokalnego resolvera (wyciek DNS), a nie przez tunel SSH.

Przekazywanie dynamiczne (-D) tworzy serwer SOCKS5 na localhost.

W przeciwieństwie do -L (które wymaga określenia konkretnego hosta i portu docelowego), -D pozwala aplikacji decydować, z którym hostem i portem chce się połączyć.

Klient SOCKS5 wysyła do proxy nazwę hosta i port, a proxy (serwer SSH) nawiązuje połączenie i przekazuje dane.

W Firefox: about:config → network.proxy.socks_remote_dns → true.

W Chrome użyj parametru --host-resolver-rules="MAP * /NOTFOUND, EXCLUDE localhost".

Tunel dynamiczny jest szczególnie przydatny w publicznych sieciach Wi-Fi (kawiarnie, lotniska): cały ruch przeglądarki jest szyfrowany od twojego laptopa do serwera SSH, chroniąc przed sniffingiem.

Można go też użyć do ominięcia geoblokad (Netflix, YouTube) – serwer SSH w innym kraju.

Cecha	-L (lokalny)	-R (zdalny)	-D (dynamiczny)
Kto otwiera port	Klient	Serwer	Klient
Port na którym końcu	Lokalnym (klient)	Zdalnym (serwer)	Lokalnym (klient)
Cel ruchu	Określony host:port (widziany z serwera)	Określony host:port (widziany z klienta)	Dowolny host:port (aplikacja decyduje)
Typ proxy	Statyczne (fixed endpoint)	Statyczne (fixed endpoint)	Dynamiczne (SOCKS5)
Zastosowanie	Dostęp do usług za firewallem	Udostępnienie usługi zza NAT	Bezpieczne proxy dla przeglądarki
Przykład	`-L 3307:localhost:3306`	`-R 8080:localhost:80`	`-D 1080`
Wymaga wielu portów	Tak (każda usługa osobno)	Tak (każda usługa osobno)	Nie (jeden port na wszystko)
Szyfrowanie	Tak (cały tunel)	Tak (cały tunel)	Tak (cały tunel)

Zasada wyboru:

Chcesz bezpiecznie dostać się do usługi w sieci serwera? → -L
Chcesz udostępnić swoją lokalną usługę przez serwer? → -R
Chcesz bezpiecznie przeglądać Internet przez serwer? → -D

Wszystkie trzy typy można łączyć w jednym połączeniu.

Wybór odpowiedniego typu tunelu zależy od kierunku inicjacji połączenia i lokalizacji usługi. -L jest najczęściej używane – łączysz się z serwerem i zyskujesz dostęp do usług w jego sieci. -R jest potrzebne, gdy usługa jest po twojej stronie (za NAT-em), a dostęp ma być z zewnątrz. -D jest uniwersalne – jeden tunel obsługuje wiele protokołów i hostów.

Przykład: -L 3307:localhost:3306 -R 8080:localhost:3000 -D 1080 user@host.

To połączenie tworzy jednocześnie tunel do MySQL, udostępnia lokalny serwer web i uruchamia proxy SOCKS5.

Opcja -f (background) i -N (no shell) są standardowo używane z tunelami. -N mówi, aby nie uruchamiać zdalnego shella, co jest bezpieczniejsze dla tuneli (mniejsza powierzchnia ataku). -f odłącza proces od terminala. Łącznie: -fNL ... dla tuneli produkcyjnych.

ssh -fNL 3307:db.internal:3306 \
  -L 5901:localhost:5900 \
  -D 1080 \
  jan@brama.example.com
# 3307 → MySQL na serwerze db.internal
# 5901 → VNC na serwerze brama
# 1080 → proxy SOCKS5 dla przeglądarki

sudo apt install autossh
autossh -M 0 -fNL 3307:localhost:3306 jan@192.168.1.100
# -M 0 wyłącza port monitorujący (w nowych wersjach)
# autossh restartuje tunel po przerwaniu połączenia

ssh -fNLC 5901:localhost:5900 jan@192.168.1.100
# -C włącza kompresję (ważne dla VNC!)
# Klient VNC: vncviewer localhost:5901

ssh -J jan@brama.example.com -L 8389:serwer-db:3389 jan@10.0.1.50
# Połączenie przez bramę do RDP na serwerze wewnętrznym
# Klient RDP: mstsc /v:localhost:8389

Przykład 1: Potrójny tunel (MySQL + VNC + SOCKS5) w jednym połączeniu

Przykład 2: Tunel z autossh – automatyczne odtwarzanie

Przykład 3: Tunel VNC przez SSH z kompresją

Przykład 4: Tunel przez bramę (ProxyJump + -L)

Obraz: diagram wielokrotnego tunelowania

Protokół SSH tuneluje wyłącznie protokół TCP.

Każda flaga -L, -R, -D dodaje kolejny kanał.

Restart=always.

Przykład 1 pokazuje, że jedna sesja SSH może obsługiwać wiele niezależnych tuneli jednocześnie.

Użyj jednej flagi -f na początku, reszta bez -f (bo proces jest już w tle).

autossh to narzędzie, które monitoruje połączenie SSH przez wysyłanie keepalive i automatycznie restartuje tunel po przerwaniu.

Jest standardem w środowiskach produkcyjnych, gdzie tunele muszą działać 24/7.

W systemd można skonfigurować tunel jako usługę: [Unit] Description= tunnel, [Service] ExecStart=/usr/bin/autossh -M 0 -NL ...

Kompresja (-C) jest szczególnie przydatna dla VNC i RDP, gdzie przesyłane są obrazy ekranu.

Dla połączeń lokalnych (LAN) kompresja może spowolnić transmisję (dodaje narzut CPU).

Dla wolnych łączy (Internet, LTE) kompresja znacząco poprawia szybkość reakcji.

VNC przez tunel (-C) jest bezpieczniejszą alternatywą dla VNC bez szyfrowania.

  Klient  Brama (publiczna)  Cel (wewnętrzny)
  ┌────────┐  ┌────────────────┐  ┌────────────────┐
  │ ssh -J │──────────│ sshd  │────────│ sshd:22  │
  │ user@  │  :2222  │ 185.10.20.30  │  :22  │ 10.0.1.50  │
  │ 10.0.1 │  │  jump host  │  │  (sieć wewn.)  │
  │ .50  │  └────────────────┘  └────────────────┘
  └────────┘
  TCP  klient → brama  brama → cel

Składnia:

ssh -J user@brama.example.com user@10.0.1.50
# Łączy się z bramą, a przez nią tunelem do 10.0.1.50

ssh -o ProxyCommand="ssh -W %h:%p user@brama.example.com" user@10.0.1.50

Łańcuch wielu skoków:

ssh -J user1@brama1,user2@brama2 user3@10.0.1.50

ProxyJump (-J):Łączy się z hostem docelowym przez jeden lub więcej hostów pośrednich (jump host / bastion host).

ProxyCommand (starsza, równoważna metoda):

Obraz: diagram ProxyJump – klient → brama → cel

Wcześniej używano ProxyCommand z ssh -W, które nadal działa.

Tylko brama ma otwarty port SSH na firewallu.

ProxyJump (-J) został wprowadzony w OpenSSH 7.3 (2016) i jest preferowanym sposobem łączenia przez bramę.

Różnica: -J jest prostsze w składni i obsługuje wiele skoków oddzielonych przecinkami.

Bastion host (brama, jump host) to serwer z publicznym adresem IP, który pełni rolę bramy do sieci wewnętrznej.

Administratorzy łączą się z bramą, a stamtąd z serwerami wewnętrznymi.

To kluczowy element bezpieczeństwa – redukuje powierzchnię ataku do jednego serwera.

Konfiguracja w ~/.ssh/config: Host *.internal ProxyJump user@brama.example.com.

Wtedy każde SSH do hosta z domeną .internal automatycznie używa bramy.

Można też zdefiniować wiele bram dla różnych sieci: Host 10.0.*.* ProxyJump user@brama1, Host 10.1.*.* ProxyJump user@brama2.

# Push (wysyłanie na serwer)
scp dokument.txt jan@192.168.1.100:/home/jan/
# Pull (pobieranie z serwera)
scp jan@192.168.1.100:/home/jan/raport.pdf ./
# Z niestandardowym portem (uwaga: duże -P!)
scp -P 2222 plik.txt jan@127.0.0.1:/tmp/
# Kopiowanie katalogu rekurencyjnie z kompresją
scp -rC projekt/ jan@192.168.1.100:/backup/

sftp jan@192.168.1.100
# sftp> ls -la
# sftp> get raport.pdf
# sftp> put dokument.txt
# sftp> chmod 755 skrypt.sh
# sftp> rm stary_plik.log
# sftp> exit

Uwaga: W OpenSSH 9.0+ SCP domyślnie używa SFTP jako backendu. Flaga -O w scp wymusza stary protokół SCP (rzadko potrzebne).

SCP (Secure Copy) – kopiowanie plików przez SSH.

Składnia podobna do cp z adresem zdalnym.

SFTP (SSH File Transfer Protocol) – interaktywny transfer plików przez SSH.

Działa jak klasyczny FTP, ale przez szyfrowany kanał.

Obraz: diagram SCP push i pull z przykładami

Ważne: składnia scp wymaga dwukropka między hostem a ścieżką.

Bez dwukropka scp uzna adres za plik lokalny.

Polecenia są podobne do klienta FTP.

Jest standardem do backupów i synchronizacji.

SCP używa tej samej autoryzacji co SSH – jeśli skonfigurowałeś klucze, SCP działa bez hasła.

Flaga -P (duże P) określa port (małe -p w scp oznacza preserve atrybutów).

SFTP oferuje więcej funkcji niż SCP: listowanie katalogów (ls), usuwanie (rm), zmianę uprawnień (chmod), tworzenie katalogów (mkdir), wznowienie przerwanego transferu (reget).

SFTP jest protokołem interaktywnym, podczas gdy SCP jest jednorazowym poleceniem.

rsync to jeszcze potężniejsze narzędzie do synchronizacji plików przez SSH: rsync -avz -e ssh /lokalny/ jan@host:/zdalny/. rsync przesyła tylko różnice między plikami (przyrostowo), co oszczędza czas i pasmo.

1. Uwierzytelnianie kluczami

PasswordAuthentication no – eliminuje ataki brute-force na hasła.

2. Zmiana domyślnego portu

Port 2222 – ogranicza automatyczne skanowanie, ale nie jest realnym zabezpieczeniem.

3. Ograniczenie użytkowników

AllowUsers jan admin – tylko ci użytkownicy mogą logować się przez SSH.

4. Limit prób logowania

MaxAuthTries 3 – automatyczne rozłączenie po 3 nieudanych próbach.

5. fail2ban

sudo apt install fail2ban
# Blokuje IP po N nieudanych próbach na czas T
# Domyślnie: 5 prób → ban na 10 minut

6. Wyłączenie logowania SSH roota

PermitRootLogin no – loguj się na zwykłego użytkownika, używaj sudo.

7. Klucze hosta – weryfikacja odcisku

Przy pierwszym połączeniu porównaj odcisk klucza: ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Obraz: lista kontrolna bezpieczeństwa SSH

Domyślna konfiguracja banuje na 10 minut po 5 próbach.

Używaj najnowszej wersji OpenSSH (obecnie 9.x).

Starsze wersje mogą mieć znane podatności.

fail2ban monitoruje logi /var/log/auth.log i blokuje adresy IP za pomocą iptables/nftables po wykryciu nieudanych prób logowania.

Można skonfigurować trwałe bany dla powtarzających się ataków (recidive jail). fail2ban chroni również inne usługi (Apache, Postfix, Dovecot).

Dodatkowe zabezpieczenia: użyj uwierzytelniania dwuskładnikowego (Google Authenticator PAM module), certyfikatów SSH (OpenSSH CA) zamiast ręcznego zarządzania kluczami, blokuj dostęp tylko z zaufanych sieci (AllowUsers z adresami IP lub reguły firewalla), wyłącz starsze algorytmy kryptograficzne (np. w sshd_config: HostKeyAlgorithms -ssh-rsa, KexAlgorithms -diffie-hellman-group1-sha1).

Regularnie audytuj konfigurację SSH: ssh-audit to narzędzie skanujące serwer SSH i oceniające bezpieczeństwo algorytmów.

Sprawdź wersję: ssh -V (klient) i na serwerze: dpkg -l openssh-server | tail -1.

Opcja	Opis	Przykład
`-p port`	Port serwera (domyślnie 22)	`ssh -p 2222 user@host`
`-i plik`	Klucz prywatny do uwierzytelnienia	`ssh -i ~/.ssh/id_ed25519 user@host`
`-L p:host:p`	Przekazywanie lokalne (tunel)	`ssh -L 3307:db:3306 user@host`
`-R p:host:p`	Przekazywanie zdalne (reverse)	`ssh -R 8080:localhost:80 user@host`
`-D port`	Dynamiczne proxy SOCKS5	`ssh -D 1080 user@host`
`-J user@host`	Połączenie przez skok (ProxyJump)	`ssh -J jump@brama user@cel`
`-C`	Kompresja danych (gzip)	`ssh -C user@host`
`-v / -vv / -vvv`	Szczegółowość diagnostyki	`ssh -vvv user@host`
`-N`	Tylko tunel, bez shella	`ssh -NL 3306:db:3306 user@host`
`-f`	Przejście do tła	`ssh -fNL 5901:localhost:5900 user@host`
`-t`	Wymuszenie pseudo-terminala	`ssh -t user@host htop`
`-o opcja=wartość`	Dowolna opcja ssh_config	`ssh -o StrictHostKeyChecking=no user@host`
`-A`	Przekazanie agenta auth	`ssh -A user@host`
`-X`	Przekazywanie X11	`ssh -X user@host`
`-c szyfr`	Wybór algorytmu szyfrowania	`ssh -c aes256-gcm@openssh.com user@host`
`-F plik`	Alternatywny plik konfiguracji	`ssh -F ~/.ssh/prod_config user@host`
`-E plik`	Zapis logów do pliku	`ssh -E /tmp/ssh.log -vvv user@host`
`-q`	Tryb cichy (quiet)	`ssh -q user@host`
`-4 / -6`	Wymuś IPv4 lub IPv6	`ssh -4 user@host`
`-b adres`	Adres źródłowy (bind)	`ssh -b 192.168.1.10 user@host`

Zapamiętaj: man ssh to najpełniejsze źródło wiedzy. Eksperymentuj w laboratorium – twórz tunele, testuj opcje, diagnozuj z -vvv.

Wymaga X11Forwarding yes w sshd_config.

Opcja -4/-6 wymusza użycie tylko IPv4 lub IPv6.

Po takiej konfiguracji wystarczy ssh prod.

Opcja -X (X11 forwarding) pozwala uruchomić zdalną aplikację graficzną na serwerze, ale wyświetlić ją lokalnie.

Działa przez SSH: ssh -X user@host, potem uruchom aplikację (na serwerze), a okno pojawi się lokalnie.

Dla macOS potrzebny XQuartz, dla Windows – Xming lub VcXsrv.

Przydatne, gdy host zwraca oba adresy, a chcesz konkretnego. -b (bind) określa interfejs źródłowy na kliencie – przydatne przy wielu interfejsach sieciowych. -E zapisuje logi debugowania do pliku zamiast na stderr, co jest przydatne przy długotrwałej diagnostyce.

Plik ~/.ssh/config to najwygodniejszy sposób zarządzania opcjami.

Przykład: Host prod HostName 192.168.1.100 User jan Port 2222 IdentityFile ~/.ssh/id_ed25519.

W pliku można definiować aliasy, tunele (-L), ProxyJump, kompresję i inne opcje dla każdego hosta.