Great write up!<p>One thing to add is that you can even open tunnels during an interactive session without disconnection.<p>To do this, type the escape command sequence ~C (will not show) and it will drop you to the control prompt. You can then add tunnels.<p><pre><code> ssh>
ssh> -L 8000:localhost:9000
Forwarding port.</code></pre>
There's a really fancy new -R feature that I love (added in 2017 I think).<p>ssh <target> -R <just a port number><p>This opens up a localhost port on the target that acts as a socks server which tunnels all your traffic through the source machine.<p>This is great for machines that you can SSH into, but are otherwise completely isolated from the network, or are monitored heavily. You can jump on, and pull down everything you need from the existing SSH connection, rather than using the machine to make requests out to the internet directly.<p>This is also good if the source machine is a web server or something on a secured network which can SSH out, but not much else, and the destination is your command and control server on the internet. Then it opens up a socks port on the C&C machine that gives full access to the internal network, impersonating the source machine.<p>Every other -R is a point to point TCP connection, but setting up a SOCKS proxy with -R is magic. More analogous to a reverse -D than a reverse -L. Super useful.
This[1] is probably the best, easiest and most (visually) effective way to learn about SSH tunnels.<p>[1] : <a href="https://unix.stackexchange.com/a/118650/289353" rel="nofollow">https://unix.stackexchange.com/a/118650/289353</a>
Drawing some diagrams helped me understand remote port forwarding and OpenSSH's port:host:port syntax: <a href="http://dirk-loss.de/ssh-port-forwarding.htm" rel="nofollow">http://dirk-loss.de/ssh-port-forwarding.htm</a>
One common use is to secure vnc, which has no crypto built into it.<p>On the remote host, have the vnc server listen only on localhost:5901<p>This assumes everyone who can ssh to the server should be allowed access.<p>On your workstation, form an ssh tunnel to that remote host and its port, and link it your own localhost:5901<p>Open your vnc client GUI and set it to open 127.0.0.1:5901, voila, vnc session.<p>More fun things: say for example you have a big remote xen dom0 with a lot of unique qemu HVM VMs running on it. Configure each of their .cfg files for xen to spawn a vnc server on localhost only and a unique port number per domU (5902,5903,5904,etc). Then use the same method to connect.
These are simply amazing. There's a stack overflow answer similar to this which I found very intuitive to understand <a href="https://unix.stackexchange.com/a/115906/254044" rel="nofollow">https://unix.stackexchange.com/a/115906/254044</a>
SSH tunnels are my favorite tool for NAT-busting. I always have to look up the cryptic syntax, but with <i>one</i> strategically placed Raspberry Pi, you can basically get from anywhere to anywhere.<p>And it works just as well on a locked down corporate network as it does on a home network. Why people put up with garbage VPN software is beyond me.
Why don't people use unix domain sockets for local connections? They are pretty much the same thing as local IP connections, except access rights apply as on files, so you're not exposing connections to pretty much all processes.<p>Domain sockets can be forwarded via ssh with the same -L and -R arguments, including cross unix/ip forwardings.
For those interested in the topic of tunneling, I highly recommend The Cyber Plumber’s Handbook [1] to gain an even deeper understanding and examples beyond SSH.<p>[1] <a href="https://cph.opsdisk.com/" rel="nofollow">https://cph.opsdisk.com/</a>
Nice reference.<p>Reaching target hosts multiple jump-hosts away, and going the wrong way through multiple firewalls segregating those lans, is another use-case of tunnels I've found handy.<p>i.e.<p>your_remote_client_host->internet->fw1->lan1->fw2->lan2->fw3->target_host<p>Target_host can be reached by doing tunnel-in-tunnel-in-tunnel-in-tunnel. Each tunnel gets you past one firewall. The final tunnel you can just ssh to fw3 via a local tunnel and a local port on your_remote_client now takes you straight to target_host.
Nicely written!<p>I once also wrote a guide to access remote IoT devices using SSH tunnels:
<a href="https://phillip.dornauer.cc/unix/iot/2019/04/12/set-up-ssh-tunnel-server.html" rel="nofollow">https://phillip.dornauer.cc/unix/iot/2019/04/12/set-up-ssh-t...</a>
Absolutely brilliant! I've had to explain local/reverse/dynamic port forwarding to people enough times that I've written a text file I can just send them, but I can finally replace that with a link to this page.
Really nice and clear. One addition: the final example uses ProxyCommand, I find ProxyJump much more useful: you can specify multiple hops clearly and even specify different private keys for each hop.
That comes in very handy. Bookmarked.<p>I also found the following very nice: (Same info but presented in a different way.)<p><a href="https://unix.stackexchange.com/questions/115897/whats-ssh-port-forwarding-and-whats-the-difference-between-ssh-local-and-remot/115906#115906" rel="nofollow">https://unix.stackexchange.com/questions/115897/whats-ssh-po...</a>
<a href="https://unix.stackexchange.com/a/115906/9745" rel="nofollow">https://unix.stackexchange.com/a/115906/9745</a>
I’ve always shared this with my team. I think OP’s post is good, but prefer the visuals of this for the `-L` and `-R` features.
Great resource. Most tutorials on SSH tunnels are strangely incomplete. This one seems to cover all the important points, and does so in an approachable way.
Every once in a while I wonder how the SOCKS5 stuff works at the protocol level, I would like to be able to SSH out without running a proxy process locally, just talk to the ssh deamon on the relay server directly. The OpenSSH code is a bit dense but it looks like it creates dynamic tunnels that are torn down when the connection closes. Anyone confirm that is what happens behind the scenes?
Great, I can refer people (and myself) to this page !<p>A lot of tunneling tutorial, medium articles and blog post mixes local and remote port forwarding and use the words interchangeably which cause a lot of confusion.