SSH tunely a přesměrování portů: vysvětlení -L, -R a -D

SSH tunel přenáší TCP spojení uvnitř SSH relace, které už důvěřuješ. Příkaz ssh -L 3307:127.0.0.1:3306 deploy@203.0.113.10 způsobí, že port 3307 na tvém notebooku vede na port 3306 na loopback rozhraní serveru, takže databáze, která poslouchá jen na 127.0.0.1, je dostupná od tvého stolu, aniž bys otevřel jediný port ve firewallu. -R dělá opak: port na serveru vede zpátky k něčemu na tvém počítači. -D změní relaci na SOCKS proxy. Tyto tři přepínače plus -N, který vynechá shell, pokryjí skoro všechno, k čemu lidé tunely používají.

Jednořádkové příklady vynechávají to, co se vymstí později: na jakou adresu se přesměrování naváže, co může server odmítnout, proč tunel přes noc tiše umře a proč přesměrování navázané na špatné rozhraní nenápadně vystaví tvou databázi internetu. Tento článek pokrývá všechno z toho a předpokládá, že se už umíš přihlásit pomocí klíče - pokud ne, začni článkem SSH klíče a zabezpečení sshd_config.

Tři druhy přesměrování ve zkratce#

Pravidlo, díky kterému je syntaxe čitelná: strana, na které port poslouchá, je ta, kterou pojmenovává přepínač, a cílového hostitele ve specifikaci překládá druhý konec. V -L 3307:db.internal:3306 název db.internal vyhledává SSH server, ne tvůj notebook, což je přesně důvod, proč tunel dosáhne na názvy a adresy, o kterých tvůj počítač nikdy neslyšel.

Každé přesměrování jede v jednom šifrovaném TCP spojení na port 22 (nebo kde jinde sshd poslouchá). Cílová služba nemusí nic vědět o tom, že je tunelovaná; vidí obyčejné TCP spojení ze serveru, na kterém běží, nebo z hostitele, ke kterému se server připojil.

Dvě omezení je dobré znát dřív, než kolem tunelů něco naplánuješ. SSH přesměrovává jen TCP - UDP přesměrování neexistuje, takže herní provoz, DNS přes UDP a většina hlasových protokolů přes -L ani -R projít nemůže. A všechny kanály sdílejí jedno TCP spojení, takže jeden velký přenos zpomalí všechna ostatní přesměrování ve stejné relaci a ztráta paketů na trase zastaví všechna naráz.

Lokální přesměrování: přístup k databázi, která poslouchá na localhostu#

S tímto případem přichází většina lidí. Server MySQL nebo PostgreSQL na VDS je správně nastavený tak, aby poslouchal jen na loopbacku - bind-address = 127.0.0.1 v MySQL, listen_addresses = 'localhost' v PostgreSQL - a ty ho chceš otevřít v grafickém klientu na vlastním počítači.

$ ssh -N -L 3307:127.0.0.1:3306 deploy@203.0.113.10

Čti to takto: poslouchej na lokálním portu 3307 a každé spojení pošli na 127.0.0.1:3306 z pohledu serveru. -N říká SSH, aby nespouštělo vzdálený shell, takže příkaz jen stojí a drží tunel otevřený, dokud nestiskneš Ctrl+C. Potom v druhém terminálu:

$ mysql -h 127.0.0.1 -P 3307 -u app -p appdb$ psql "host=127.0.0.1 port=5433 user=app dbname=appdb"   # for a -L 5433:...:5432

O tom, jestli to napoprvé funguje, rozhodují tři detaily.

• Na straně klienta používej `127.0.0.1`, ne `localhost`. Klient MySQL bere localhost jako "použij lokální Unix socket" a port ignoruje, takže mysql -h localhost -P 3307 se připojí k jakémukoli MySQL, které běží na tvém notebooku, nebo selže, ale tunelu se nikdy nedotkne. Vzdálená připojení k MySQL toto chování vysvětlují celé.
• Vyber lokální port, který je volný. Přesměrování 3306 na 3306 selže s chybou bind [127.0.0.1]:3306: Address already in use, jakmile ti lokálně běží MySQL. Zvyk použít skutečný port plus jedna (3307, 5433) tomu předchází. Na Linuxu vyžaduje navázání na lokální port pod 1024 root, což je další důvod zůstat nad touto hranicí.
• Databáze vidí spojení přicházející ze samotného serveru. Pro MySQL to znamená, že účet musí existovat pro 127.0.0.1 nebo localhost (to druhé odpovídá jen tehdy, když je zapnuté překládání jmen, což je ve výchozím stavu). Pro PostgreSQL spojení přichází přes TCP z 127.0.0.1, takže pg_hba.conf potřebuje řádek host pro 127.0.0.1/32; většina distribučních balíčků jeden obsahuje. Tunel neobchází autentizaci databáze - jen tě dovede ke dveřím.

Přesměrování na jiný počítač nebo na Unix socket

Cílem nemusí být SSH server. Pokud databáze leží na privátní adrese za strojem, na který se umíš přihlásit, pojmenuj ji:

$ ssh -N -L 5433:10.0.0.20:5432 deploy@203.0.113.10

SSH server nyní naváže spojení na 10.0.0.20:5432 tvým jménem. Tento úsek mezi serverem a databází SSH nešifruje; je to obyčejné TCP spojení v privátní síti. V síti, kterou ovládáš, to obvykle nevadí, a je dobré to říct nahlas, když to vadí.

OpenSSH 6.7 a novější umí přesměrovat také na Unix socket na serveru, díky čemuž se dostaneš k databázi, která nemá žádný TCP listener:

$ ssh -N -L 5433:/var/run/postgresql/.s.PGSQL.5432 deploy@203.0.113.10

PostgreSQL pak vidí spojení přes lokální socket a pg_hba.conf použije svá pravidla local místo pravidel host. Přesměrování socketů se na serveru řídí zvlášť direktivou AllowStreamLocalForwarding, která má výchozí hodnotu yes.

Trvalé tunely přes ~/.ssh/config#

Psát specifikaci pokaždé omrzí a konfigurační soubor přijímá totéž pod jménem:

Host db-tunnel    HostName 203.0.113.10    User deploy    IdentityFile ~/.ssh/id_ed25519    LocalForward 3307 127.0.0.1:3306    LocalForward 5433 127.0.0.1:5432    ExitOnForwardFailure yes    ServerAliveInterval 30    ServerAliveCountMax 3

ssh -N db-tunnel teď otevře obě přesměrování. Všimni si, že LocalForward odděluje poslouchající port a cíl mezerou, ne dvojtečkou. RemoteForward a DynamicForward existují se stejným tvarem.

ExitOnForwardFailure yes je volba, kterou přidej vždy. Bez ní, když je port už obsazený, SSH vypíše varování, přesto tě přihlásí a nechá tě s relací bez tunelu - což vypadá stejně jako funkční, dokud se klient nepřipojí. S ní SSH skončí s chybou a cokoli, co ho dohlíží, to může zkusit znovu.

Pokud je databázový stroj dostupný jen přes bastion, kombinuj přesměrování s ProxyJump místo ručního řetězení dvou tunelů. ssh -J bastion -N -L 5433:127.0.0.1:5432 deploy@10.0.0.20 se připojí přes bastion k vnitřnímu stroji a přesměruje odtud, přičemž autentizace na každém skoku probíhá na tvém notebooku.

Dva další přepínače stojí za znalost. -f pošle SSH po autentizaci do pozadí, což se hodí pro skripty: ssh -f -N db-tunnel. A do už otevřené relace můžeš přidat přesměrování pomocí escape sekvence ~C napsané na začátku řádku, následované -L 8080:127.0.0.1:80. Od OpenSSH 9.2 je tento příkazový řádek ve výchozím stavu vypnutý a vyžaduje EnableEscapeCommandline yes v konfiguraci klienta.

Vzdálené přesměrování: zpřístupnění něčeho na tvém počítači#

-R otevře na serveru poslouchající port a posílá spojení zpět přes relaci na tvou stranu.

$ ssh -N -R 8080:127.0.0.1:3000 deploy@203.0.113.10

Spojení na port 8080 na serveru teď dosáhnou na 127.0.0.1:3000 na tvém notebooku - vývojový webový server, příjemce webhooků, který ladíš, nebo službu v domácí síti bez veřejné adresy. Je to stejná myšlenka, kterou balí komerční tunelovací služby, jen bez třetí strany.

Tady je překvapení, které potká skoro každého: ve výchozím stavu vzdálený port poslouchá jen na loopbacku serveru. Spusť na serveru ss -tlnp a uvidíš 127.0.0.1:8080, ne 0.0.0.0:8080, takže se k němu nikdo z internetu nedostane. Toto výchozí chování řídí GatewayPorts v sshd_config na serveru:

S clientspecified si klient vybere adresu ve specifikaci: -R 0.0.0.0:8080:127.0.0.1:3000 žádá všechna rozhraní a -R 8080:... stále dostane loopback. To je bezpečnější z obou nevýchozích hodnot, protože z vystavení dělá záměrný krok u každého tunelu místo vedlejšího efektu každého z nich.

Častější a bezpečnější postup je nechat GatewayPorts no a před loopback port postavit na serveru reverzní proxy. Nginx poslouchající na 443 s certifikátem a předávající na 127.0.0.1:8080 dá přesměrované službě pořádné jméno a TLS a surový port tunelu nikdy není veřejný. Pokud port místo toho otevřeš ve firewallu, průvodce ufw popisuje, jak ho povolit jen z adres, které ho potřebují.

Vzdálený port 0 požádá server, aby vybral volný, a vypíše ho, což se hodí ve skriptech. A od OpenSSH 7.6 vytvoří -R jen s portem a bez cíle (-R 1080) na serveru SOCKS proxy, která vystupuje přes tvůj počítač - zrcadlový obraz -D.

Dynamické přesměrování: SOCKS proxy jedním přepínačem#

$ ssh -N -D 1080 deploy@203.0.113.10

Tohle spustí proxy SOCKS4 a SOCKS5 na 127.0.0.1:1080. Každé aplikaci namířené na ni se každé spojení otevře ze serveru místo z tvého počítače, na jakýkoli cíl, který si vyžádá. Nasměruj na ni prohlížeč a budeš prohlížet z adresy serveru; nasměruj na ni databázový nástroj a dostaneš se na každého privátního hostitele, na kterého se dostane server.

$ curl --socks5-hostname 127.0.0.1:1080 http://10.0.0.20:9000/health

--socks5-hostname je důležité: pošle jméno proxy k přeložení místo lokálního překladu. Samotné --socks5 jméno nejdřív vyhledá na tvém počítači, což u interních jmen selže a prozradí dotaz tvému lokálnímu resolveru. Prohlížeče mají stejný přepínač - ve Firefoxu je to volba pro proxy DNS při použití SOCKS v5.

SOCKS proxy přes SSH je rozumný způsob, jak se dostat k administračnímu rozhraní v privátní síti nebo zkontrolovat, jak web odpovídá ze serveru v jiné zemi. Není to VPN: projdou jí jen aplikace nastavené k použití proxy, UDP ne a cokoli, na co zapomeneš ji nasměrovat, odchází přímo. Pokud ve skutečnosti chceš, aby veškerý provoz zařízení šel přes server, správným nástrojem je skutečná VPN - co VPN chrání a co ne vede tuto hranici.

Udržení tunelu naživu: autossh a systemd#

Ručně otevřený tunel zemře s wifi notebooku, s routerem, který zahazuje nečinné relace, a s každým restartem serveru. Tunel, na kterém něco závisí - úloha pro reporty čtoucí vzdálenou databázi, domácí služba zpřístupněná přes -R - potřebuje dohled.

První obranou je dvojice keepalive voleb, ServerAliveInterval 30 a ServerAliveCountMax 3. Klient díky nim posílá každých 30 sekund sondu šifrovaným kanálem a po třech nezodpovězených to vzdá, takže mrtvé spojení se pozná asi za 90 sekund místo věčného visení. Vzdát to je přesně to, co chceš: proces, který skončí, lze restartovat.

autossh je klasický restartér. Spustí ssh a znovu ho nastartuje, kdykoli skončí.

$ autossh -M 0 -f -N \    -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" \    -o "ExitOnForwardFailure yes" \    -L 3307:127.0.0.1:3306 deploy@203.0.113.10

-M 0 vypne vlastní monitorovací port autossh a spoléhá místo toho na keepalive SSH, což je dnes obvyklé nastavení. Jedno chování je dobré znát: ve výchozím stavu autossh bere ssh, který skončí během prvních 30 sekund, jako fatální chybu a zastaví se (řídí to proměnná prostředí AUTOSSH_GATETIME), čímž zachytí špatné heslo nebo klíč hostitele místo věčného opakování. Při spuštění s -f nastaví tuto dobu na nulu a opakuje dál.

Na Linuxu se systemd autossh vůbec nepotřebuješ. Unit s Restart=always dělá stejnou práci a ukládá logy do žurnálu:

[Unit]Description=SSH tunnel to the databaseAfter=network-online.targetWants=network-online.target[Service]User=tunnelExecStart=/usr/bin/ssh -N -o ExitOnForwardFailure=yes \  -o ServerAliveInterval=30 -o ServerAliveCountMax=3 \  -i /home/tunnel/.ssh/id_ed25519 -L 3307:127.0.0.1:3306 tunnel@203.0.113.10Restart=alwaysRestartSec=10[Install]WantedBy=multi-user.target

$ sudo systemctl daemon-reload$ sudo systemctl enable --now db-tunnel$ journalctl -u db-tunnel -f

Dvě věci dělají toto řešení bezpečným k ponechání v běhu. Klíč, který používá, nemá passphrase - musí tomu tak být, nikdo tam není, aby ji zadal - proto to musí být vyhrazený klíč pro vyhrazený účet, omezený na serveru na jediné přesměrování, které potřebuje, jak ukazuje další část. A první připojení se musí jednou provést ručně jako tento uživatel, aby se klíč hostitele přijal do jeho known_hosts; služba na otázku o otisku odpovědět nedokáže a nikdy by se neměla nastavovat s StrictHostKeyChecking no, aby se tomu vyhnula.

Co server povoluje: AllowTcpForwarding a spol.#

Všechno výše funguje proto, že server OpenSSH ve výchozím stavu přesměrování povoluje. To je správné výchozí nastavení pro administrátorův vlastní účet a špatné pro většinu ostatních. Tohle jsou ovládací prvky, všechny v sshd_config:

Lidé přehlížejí, že přesměrování nepotřebuje shell. Uživatel, jehož účet je zamčený na SFTP přes ForceCommand internal-sftp nebo jehož shell je /usr/sbin/nologin, může stále spustit ssh -N -L ... a použít tvůj server jako odrazový můstek do jeho privátní sítě, pokud mu není přesměrování vypnuto. Proto by blok Match pro omezené účty měl říkat výslovně:

Match Group sftp-only    AllowTcpForwarding no    AllowStreamLocalForwarding no    X11Forwarding noMatch User tunnel    AllowTcpForwarding local    PermitOpen 127.0.0.1:3306    X11Forwarding no

Stejná omezení lze nastavit pro každý klíč v authorized_keys, což je čistší možnost pro servisní účet s jedním úkolem:

restrict,port-forwarding,permitopen="127.0.0.1:3306",command="/bin/false" ssh-ed25519 AAAAC3Nza... tunnel@reporting

restrict vypne všechno volitelné, port-forwarding přesměrování znovu zapne, permitopen ho omezí na port databáze a vynucený příkaz znamená, že klíč nemůže spustit nic, ani kdyby si někdo vyžádal shell - -N žádný příkaz nespouští, takže tunel to neovlivní. permitlisten je ekvivalent pro klíč, který má vytvářet jen jeden port -R. Ukradená kopie takového klíče pak má cenu právě jednoho připojení k databázi, které se stále musí autentizovat vůči databázi.

Jako vždy u sshd testuj pomocí sshd -t a před restartem nech otevřenou stávající relaci.

Bezpečnostní úskalí, která je třeba brát vážně#

Tunel je šifrovaný, autentizovaný a pohodlný a každá z těch vlastností usnadňuje zapomenout, že je zároveň dírou v jakékoli hranici, kterou jsi nakreslil.

• Lokální přesměrování je otevřené každému na tvém počítači. -L 3307:... se váže na 127.0.0.1, takže se k němu může připojit každý proces a každý uživatel na tom počítači. Na notebooku, který používáš jen ty, je to v pořádku. Na sdíleném jump boxu nebo build serveru to předává připojení k tvé databázi každému, kdo má login. Heslo k databázi stále platí; plánuj, jako by byl port veřejný.
• Nikdy nevaž přesměrování na všechna rozhraní omylem. -g, GatewayPorts yes v konfiguraci klienta nebo specifikace jako -L 0.0.0.0:3307:... způsobí, že přesměrování poslouchá i na tvé síti. V kavárenské síti to znamená, že tvou databázi nabízíš celé místnosti. -D 0.0.0.0:1080 je horší: otevřená proxy do privátní sítě serveru.
• Vzdálená přesměrování mohou obejít tvůj vlastní firewall. -R z notebooku uvnitř kancelářské sítě na server mimo ni zveřejní interní službu každému, kdo se dostane na ten port serveru. Organizace blokují odchozí SSH přesně z tohoto důvodu. Netuneluj ven ze sítě, jejíž vlastník by namítal.
• Poslední úsek může být nešifrovaný. -L 5433:10.0.0.20:5432 šifruje až k SSH serveru a dál ne. Pro cokoli, co prochází sítí, které nedůvěřuješ, použij vlastní TLS databáze.
• Přeposílání agenta není přesměrování portů. -A vystavuje tvé klíče rootovi na vzdáleném hostiteli a pro nic z výše uvedeného není potřeba. Článek o SSH klíčích vysvětluje, proč ho nahrazuje ProxyJump.

Upřímné srovnání je s prostým vystavením služby. Databáze otevřená do internetu s TLS a silným heslem, na kterou se připojuješ přímo, je legitimní návrh - kontrolní seznam zabezpečení databáze pokrývá, co to obnáší. Databáze na loopbacku, dostupná jen přes SSH, odstraní přihlášení k databázi z útočné plochy úplně. Tunel je obvykle lepší volba pro administrátory a příležitostné nástroje a přímé připojení je obvykle lepší pro aplikace, které se potřebují připojovat celý den bez dohlížecího procesu, který by musel hlídat.

Řešení chyb, na které lidé narážejí#

`bind [127.0.0.1]:3306: Address already in use` a `Could not request local forwarding.` Na tvém počítači už na tom portu něco poslouchá - často lokální databáze nebo včerejší tunel, který stále běží na pozadí. Vyber jiný lokální port nebo najdi starý proces pomocí ss -tlnp na Linuxu, lsof -iTCP:3306 -sTCP:LISTEN na macOS nebo netstat -ano | findstr 3306 na Windows.

`channel 2: open failed: connect failed: Connection refused`. Tunel je v pořádku; odmítl cíl. SSH server se pokusil připojit k hostiteli a portu z tvé specifikace a nic tam neposlouchalo. Zkontroluj, že služba běží a na adrese, kterou jsi uvedl: databáze navázaná na privátní adresu odmítne 127.0.0.1 a ta navázaná na loopback odmítne privátní adresu.

`channel 2: open failed: administratively prohibited: open failed`. Politika serveru řekla ne: AllowTcpForwarding no, PermitOpen, který neobsahuje tvůj cíl, nebo klíč restrict bez port-forwarding. Je to odpověď konfigurace, ne sítě.

`Warning: remote port forwarding failed for listen port 8080`. Server nemohl otevřít port pro tvé -R: je používaný (často předchozí relací, které ještě nevypršel čas), je pod 1024 a ty nejsi root, nebo ho PermitListen vylučuje. Mrtvá relace držící port je u dohlížených tunelů běžná; uklidí ji ClientAliveInterval na serveru.

Tunel se připojí, ale klient visí. Obvykle klient tunel vůbec nepoužívá - localhost jde přes cestu k socketu, nebo grafický nástroj má vlastní nastavení SSH tunelu nakonfigurované navíc k tvému. Nejdřív otestuj pomocí nc -vz 127.0.0.1 3307: pokud se připojí, tunel funguje a problém je v klientu.

Tunel po nějaké době nečinnosti umře. Router nebo firewall mezi tebou a serverem zahodil nečinné TCP spojení. Přidej ServerAliveInterval 30 a dohlížej na všechno, co musí zůstat naživu.

Kde tunely zapadají do RE:NODE#

Každá technika v tomto článku potřebuje stroj s sshd, který spravuješ, což na RE:NODE znamená VDS: plný přístup root, takže sshd_config, GatewayPorts a omezení přesměrování nastavuješ ty. První hodina na novém VDS popisuje, jak stroj dovést do stavu, kdy je tunel dalším krokem.

Databázové tarify fungují jinak a tunel nepotřebují vůbec. Server PostgreSQL, MySQL, MongoDB, SQL Server nebo Valkey na hostingu databází je dostupný přímo na hostiteli a portu zobrazeném v panelu, s přihlašovacími údaji vygenerovanými pro daný server, takže se klient připojuje jako k jakékoli vzdálené databázi - s TLS a silným heslem, které dělají to, co jinde tunel. Herní servery, aplikace a weby mají SFTP u každého serveru a konzoli v panelu, takže běžné důvody, proč lidé otevírají tunely ke svým vlastním strojům, se řeší tam.

FAQ#

Je SSH tunel totéž co VPN?

Ne. Tunel přesměrovává konkrétní porty TCP, nebo přes -D proxuje aplikace nastavené k jeho použití, přes jedno spojení SSH. VPN směruje veškerý provoz zařízení na úrovni IP, včetně UDP a DNS. SSH umí tunelování vrstvy 3 přes ssh -w a PermitTunnel, ale je to nemotorné a účelově vytvořená VPN to dělá lépe.

Mohu přesměrovat UDP přes SSH?

Ne přes přesměrování portů OpenSSH, které je jen TCP. Existují obejití, která na obou koncích balí UDP do TCP pomocí socat, ale přidávají latenci a rozbíjejí časování, na které se spoléhají protokoly v reálném čase, například herní provoz. Pro herní server použij pořádný tunel nebo hostovaný server, ne SSH.

Zpomalí tunel mé databázové dotazy?

Mírně a zřídka natolik, aby na tom záleželo. Šifrování na moderních CPU stojí velmi málo; skutečnými náklady jsou dodatečná latence trasy a to, že všechna přesměrování sdílejí jedno TCP spojení. Pro administrační relaci nebo noční report je to neviditelné. Pro aplikaci, která posílá tisíce malých dotazů za sekundu, se připoj místo toho přímo s TLS.

Jaký port mám použít na své straně?

Jakýkoli volný port nad 1024. Skutečný port služby plus jedna (3307 pro MySQL, 5433 pro PostgreSQL) se snadno pamatuje a vyhne se kolizi s čímkoli, co běží lokálně. Čísla portů na tvé straně a na straně serveru jsou nezávislá.

Mohu používat SSH tunely na Windows?

Ano. Windows 10 a 11 obsahují klienta OpenSSH a každý příkaz zde funguje v PowerShellu nebo příkazovém řádku. PuTTY má stejnou funkci pod Connection, SSH, Tunnels s volbami Local, Remote a Dynamic. Mnoho grafických databázových nástrojů, včetně DBeaveru a MySQL Workbench, má také vestavěnou záložku pro SSH tunel.