ssh tunnel

De technische basis staat in RFC 4254, The Secure Shell (SSH) Connection Protocol, gepubliceerd op 6 januari 2006. Dit RFC definieert hoe SSH één geauthenticeerde transportverbinding multiplexet naar meerdere logische kanalen. Eén daarvan is TCP/IP forwarding — port forwarding. Een enkele SSH-verbinding kan dus meerdere netwerkdiensten tegelijk veilig doorsturen.

De termen port forwarding en tunneling worden in technische documentatie als synoniem gebruikt. De documentatie van Apache MINA SSHD stelt expliciet dat TCP/IP port forwarding hetzelfde is als tunneling: het proxyen van een TCP/IP-verbinding via een SSH-kanaal. De transportlaag zelf wordt beschreven in RFC 4253, The Secure Shell (SSH) Transport Layer Protocol, ook gepubliceerd op 6 januari 2006. RFC 4253 behandelt sleuteluitwisseling en authenticatie. Pas daarna wordt de connection layer beschikbaar waarin port forwarding is gedefinieerd.

Stappen: lokale port forwarding

Lokale port forwarding is de meest gebruikte vorm. Je koppelt een lokale poort op je eigen machine aan een poort op een externe server, via een SSH-verbinding. Red Hat documenteert het commando als:

ssh -L local-port:remote-hostname:remote-port user@hostname

Stap 1: Bepaal de tunnelparameters

Kies een lokale poort die vrij is op je machine. Kies de remote-hostname en remote-port van de dienst die je wilt bereiken, gezien vanaf de SSH-server. Voor een webserver op de SSH-server zelf gebruik je `localhost` als remote-hostname en `80` als remote-port.

Stap 2: Open de tunnel

ssh -L 8080:localhost:80 user@192.168.1.10

De SSH-client luistert nu op lokale poort 8080. Elke verbinding naar die poort wordt versleuteld naar de SSH-server gestuurd. Vanaf de server wordt het verkeer doorgestuurd naar `localhost:80` — de webserver op de SSH-server zelf. De SSH-server blijft actief op de voorgrond; je ziet de shell-prompt van de server.

Stap 3: Maak verbinding via de tunnel

Open een tweede terminal op je lokale machine en typ:

curl http://localhost:8080

Je krijgt de HTTP-response van de webserver op de SSH-server, zonder dat poort 80 op de server extern bereikbaar hoeft te zijn.

Stappen: reverse port forwarding

Reverse port forwarding gebruik je wanneer een externe partij toegang moet krijgen tot een dienst op jouw lokale machine, terwijl jij achter een firewall of NAT zit. De optie `-R` schakelt een poort op de SSH-server door naar een poort op de client.

Stap 4: Start reverse forwarding

ssh -R 9000:localhost:3000 user@192.168.1.10

De SSH-server luistert nu op poort 9000. Verkeer dat daar binnenkomt, reist door de SSH-tunnel naar jouw lokale machine en komt uit op `localhost:3000` — bijvoorbeeld een lokale ontwikkelserver. Dit wordt vaak gebruikt voor on-site ondersteuning of het debuggen van applicaties op een lokaal ontwikkelplatform.

Stap 5: Test de reverse tunnel vanaf de server

curl http://localhost:9000

Voer dit uit in een SSH-sessie op de server zelf. Je krijgt de response van de dienst op jouw lokale machine.

Stappen: dynamische port forwarding

Dynamische port forwarding creëert een SOCKS-proxy op de lokale machine. In tegenstelling tot vaste forwarding, waar je een specifieke host en poort opgeeft, stuurt dynamische forwarding elke verbinding die via de SOCKS-poort binnenkomt door de SSH-tunnel. De bestemming bepaalt de client zelf.

Stap 6: Start dynamische forwarding

ssh -D 1080 user@192.168.1.10

De SSH-client draait nu een SOCKS5-proxy op lokale poort 1080. Je kunt deze proxy instellen in een browser, of gebruiken met tools zoals `curl`:

curl --socks5-hostname localhost:1080 http://example.com

Deze techniek is handig voor veilig browsen via een externe server of voor het bereiken van meerdere interne diensten zonder vooraf port-forwarding in te stellen.

Configuratie en beperkingen

De SSH-client leest zijn configuratie uit `ssh_config`; de server uit `sshd_config`. Standaard is port forwarding toegestaan. Beheerders kunnen het beperken of uitschakelen om tunneling naar interne diensten te voorkomen.

De belangrijkste serveroptie is `AllowTcpForwarding`. Zet je deze op `no`, dan weigert de server alle forwarding-verzoeken:

<h2>/etc/ssh/sshd_config</h2>
AllowTcpForwarding no

Na een wijziging herstart je de SSH-daemon:

sudo systemctl restart sshd

De `sshd`-daemon luistert standaard op poort 22 en start automatisch bij het opstarten van het systeem, via systemd of `/etc/init.d/ssh`.

Verificatie

Controleer of de tunnel actief is met:

ss -tlnp | grep -E '8080|9000|1080'

Dit toont de luisterende poorten op je lokale systeem. Voor een uitgebreidere check van de SSH-verbinding zelf:

ssh -v -L 8080:localhost:80 user@192.168.1.10

De `-v` vlag toont gedetailleerde debug-output, inclusief de totstandkoming van de tunnel.

Veelgestelde problemen

1. "bind: Address already in use"

De lokale poort is al bezet. Kies een andere poort of sluit het proces dat de poort gebruikt:

sudo lsof -i :8080

2. "channel 0: open failed: connect failed"

De SSH-server kan de remote-hostname of remote-port niet bereiken. Controleer of de dienst draait op de server en of de remote-hostname correct is vanaf de server gezien. Gebruik `localhost` als de dienst op de SSH-server zelf draait.

3. "Permission denied (publickey)"

De server accepteert geen wachtwoordauthenticatie. Gebruik SSH-sleutels in plaats van wachtwoorden — dit verhoogt ook de beveiliging van je tunnels. Genereer een sleutelpaar:

ssh-keygen -t ed25519
ssh-copy-id user@192.168.1.10

Beveiligingsoverwegingen

Een verkeerd ingestelde tunnel kan interne diensten onbedoeld blootstellen. Beheer de instellingen in `sshd_config` zorgvuldig. Gebruik SSH-sleutels in plaats van wachtwoorden voor authenticatie. Overweeg `AllowTcpForwarding` expliciet in te stellen, ook als je forwarding wilt toestaan — de default kan per distributie verschillen.

De SSH-standaard is het resultaat van collectieve ontwikkeling binnen de internetgemeenschap. De specificaties omvatten RFC 4250 tot en met RFC 4256, die samen de officiële basis vormen voor moderne SSH-implementaties zoals OpenSSH. Een exacte uitvinder of plaats van ontstaan is niet gedocumenteerd; de huidige standaard is gegroeid door jarenlange bijdragen van verschillende auteurs en organisaties.

De drie vormen van forwarding — lokaal, reverse en dynamisch — dekken de meeste praktische scenario's. Lokale forwarding voor het bereiken van interne diensten, reverse forwarding voor het ontsluiten van lokale diensten naar buiten, en dynamische forwarding voor flexibele SOCKS-proxy toegang. Welke vorm je kiest hangt af van de richting waarin het verkeer moet stromen en of de bestemming vooraf bekend is.

De kracht van SSH-tunneling zit in de eenvoud: je hebt geen extra software nodig, alleen een werkende SSH-verbinding. Maar die eenvoud verleidt ook tot slordigheid — een tunnel die je niet meer gebruikt, moet je sluiten. Een vergeten reverse tunnel kan een ontwikkelomgeving blootstellen aan het hele netwerk van de server. De controle over je tunnels is net zo belangrijk als de mogelijkheid om ze te openen.