Firewalls are good – firewalls that are outside of your control, aren’t. I’ve been working with a client to install a network monitoring device within their network – unfortunately they have no sensible way of giving me access to it through the firewall – no available routable IPs, no port forwarding, nothing useful what so ever. This has somewhat cramped my style – making it a pain to get to the device in any way other than being in their offices. Well, I had to be there for a few days anyway – but I finally got round to implementing the solution to the problem today. I’ve used SSh tunnels for over 15 years now, originally between university Unix boxes and Linux servers at the ISP that I worked for part-time so that I could do things all round ( Uni work in the office, office work from Uni … both from home via dial-up to work … nothing from the student union because mobile computing hadn’t been invented & the beer was cheap … ) – and every so often I end up revisiting them to either (a) bypass other people’s security controls or (b) to tunnel unencrypted protocols over a secure channel. The really nice thing about SSh tunnelling is that it is actually pretty platform agnostic – PuTTY & Cygwin on Windows, MacOS X, Linux, UNIX and even Android – all have support for it one way or another.
I have always admired the programmers virtues, despite not being a programmer myself much – I feel that they should apply to all who work in IT – laziness, impatience and hubris. And in the spirit of the first, on this occasion, rather than reading the man pages and trying to recall how it all hangs together – I went to the ultimate lazy resource ( Google ) and found this script here:
#!/bin/sh # $REMOTE_HOST is the name of the remote system REMOTE_HOST=my.home.system # $REMOTE_PORT is the remote port number that will be used to tunnel # back to this system REMOTE_PORT=5000 # $COMMAND is the command used to create the reverse ssh tunnel COMMAND="ssh -q -N -R $REMOTE_PORT:localhost:22 $REMOTE_HOST" # Is the tunnel up? Perform two tests: # 1. Check for relevant process ($COMMAND) pgrep -f -x "$COMMAND" > /dev/null 2>&1 || $COMMAND# 2. Test tunnel by looking at "netstat" output on $REMOTE_HOST ssh $REMOTE_HOST netstat -an | egrep "tcp.*:$REMOTE_PORT.*LISTEN" \ > /dev/null 2>&1 if [ $? -ne 0 ] ; then pkill -f -x "$COMMAND" $COMMAND fi
This, coupled with a cron job to run it every five minutes and shared keys mean that my tunnel now remains open on my server, allowing me to get in remotely, fiddle with things move files etc. etc. etc.
Ironically, though, rather than making my life easier this now means that I can worry about what it is doing at 3am _and find out_ !