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 — poortforwarding. Een enkele SSH-verbinding kan dus meerdere netwerkdiensten tegelijk veilig doorsturen.

De termen poortforwarding en tunneling worden in technische documentatie als synoniem gebruikt. De documentatie van Apache MINA SSHD stelt expliciet dat TCP/IP-poortforwarding 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 poortforwarding is gedefinieerd.

Stappen: lokale poortforwarding

Lokale poortforwarding is de meest gebruikte vorm. U koppelt een lokale poort op uw 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 uw machine. Kies de remote-hostname en remote-port van de dienst die u wilt bereiken, gezien vanaf de SSH-server. Voor een webserver op de SSH-server zelf gebruikt u `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; u ziet de shell-prompt van de server.

Stap 3: Maak verbinding via de tunnel

Open een tweede terminal op uw lokale machine en typ:

curl http://localhost:8080

U 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 poortforwarding

Reverse poortforwarding gebruikt u wanneer een externe partij toegang moet krijgen tot een dienst op uw lokale machine, terwijl u 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 uw 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. U krijgt de response van de dienst op uw lokale machine.

Stappen: dynamische poortforwarding

Dynamische poortforwarding creëert een SOCKS-proxy op de lokale machine. In tegenstelling tot vaste forwarding, waar u 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. U 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 poortforwarding in te stellen.

Configuratie en beperkingen

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

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

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

Na een wijziging herstart u 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 uw lokale systeem. Voor een uitgebreidere controle 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 reeds 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-poort niet bereiken. Controleer of de dienst draait op de server en of de remote-hostname correct is vanuit de server bekeken. Gebruik `localhost` als de dienst op de SSH-server zelf draait.

3. "Permission denied (publickey)"

De server aanvaardt geen wachtwoordauthenticatie. Gebruik SSH-sleutels in plaats van wachtwoorden — dit verhoogt ook de beveiliging van uw 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 om `AllowTcpForwarding` expliciet in te stellen, ook als u forwarding wilt toestaan — de standaardwaarde 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 u kiest hangt af van de richting waarin het verkeer moet stromen en of de bestemming op voorhand bekend is.

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