The Agile Micro ISV Blog

Image via Wikipedia

The third and final part of this mini series (trilogy?) is on
reverse tunnelling, or remote forwarding. Let me give you an example of
when this might be useful:

Let’s say you’re on a client’s site. Let’s say your client has a
build server that’s only accessible from the internal network. Let’s
also say that your client is a humungous corporate blob, with 8
signatures and 6 weeks lead time in getting VPN
set up for you. Or maybe if you’re a consultant they won’t let you have
VPN at all. Mentioning no names…. – You need to be able to kick
off a build at some point over a weekend. And since the client’s site
is a gazillion miles from your home, you’d rather not hang around.

No problem. SSH is here to save the day. Our hypothetical build
server sits on 192.168.1.123 on the client’s internal network. It is
also set up for access via Remote Desktop. While you’re still in the office, we establish a session thus:

putty username@mydomain.com -R 9999:192.168.1.123:3389

This is telling the sshd daemon on your home server to bind to port
9999 and listen for incoming connections. Any incoming connections are
forwarded through the tunnel, to port 3389 on 192.168.1.123 on your clients network.

My home server runs at 192.168.1.101 on my network. So when I’m at
home, if I want to connect to my client’s build machine, I instruct my
remote desktop to connect to 192.168.1.101:9999 and as if by magic, I’m
now on the build machine. Awesome.

SSH is a really awesome workhorse, and if you’re a web worker,
consultant, micro ISV etc I really recommend spending a few moments to
get to grips with it.