SSH Tunnels, Simplified

Photo by Mathew Schwartz on Unsplash

SSH tunnels are mostly overlooked concept that some people even don’t know that they exist at all. Some people do know but either too lazy to use because it requires some fiddling with parameters and such, or just some other method may be convenient enough.

In order to bring it more remember-able way, I like to put stuff in sentence. It gives me chance to understand idea behind it and construct mentality to re-build from scratch. Even if I didn’t recall exact thing.

The general structure of SSH forwarding goes like;

Make this (first) pair act like next (second) pair.

Local Forwarding:

Allows you to ‘localize’ remote address. So, remote resource can be accessed via the localhost.

ssh -L MyPort:RemoteAddr:RemotePort remoteUser@remoteServer

Remote (Reverse) Forwarding:

Since you learned normal version, this is the reverse. So, it makes your side mirrored on the remote host. Eg: localhost accessible at the connected host.

ssh -R RemotePort:LocalAddr:LocalPort remoteUser@remoteServer

Unix Socket Forwarding:

Yes, you can also do TCP-to-UNIX and UNIX-to-TCP mapping, in both ways. Even UNIX-to-UNIX mapping works!

ssh -L /path/to/unix:172.17.0.1:80  ...
ssh -L 8000:/var/run/docker.sock    ...
ssh -R /path/to/unix:192.168.1.1:80 ...
ssh -R 8080:/var/run/docker.sock    ...
ssh -L /var/run/docker.sock:/var/run/docker.sock ...
ssh -R /var/run/docker.sock:/var/run/docker.sock ...

From top to bottom;

• Access locally/path/to/unix to use 172.17.0.1:80 on servers’ side
• Access locallylocalhost:8000 to use /var/run/docker.sock on servers’ side.
• Access servers’ /path/to/unix to use locally accessible 192.168.1.1:80
• Access servers’ localhost:8080 to use locally accessible /var/run/docker.sock
• Map server’s docker.sock to local docker.sock. Queries on local gets executed on server…
• Map local docker.sock to server’s docker.sock. Queries on remote gets executed locally…

Dynamic (Socks) Forwarding & Proxying:

This method allows you to have ‘dynamic’ forwarding. This means that you do not specify the “remote part” of the command. So, that is given on demand to the socket thanks to SOCKS proxy protocol.

ssh -D localPort remoteUser@remoteServer

If your SSH version is relatively new, you can also do “reverse dynamic” forward. That means remote machine can go through yours in a dynamic way.

ssh -R remotePort remoteUser@remoteServer

This will fail if your SSH client does not support that… It is completely client side.

Cheat Sheet