The power and felixibility of OpenSSH tunneling in the cloud

If you didn't realise it, the secure shell that is used every day, all over the internet is written and managed by the OpenBSD project team, and we all owe them a huge debt of thanks for their efforts. It lets us communicate securely with our servers and other devices.

Well, one of the great features of ssh , is the ability to set up tunnels , that you can use to connect traffic across , and indeed reverse tunnels which can be very useful for connecting to remote servers.

As this tool has become so ubiquitous, there are other tools that have been built around it, and some examples of these are autossh, which allows you keep a tunnel monitored and open for when you need it. Also corkscrew , which allows you to connect to remote hosts by encapsulating you traffic in https packets, thus cutting holes through proxies.

When these are combined you have the ability to connect to remote hosts, hidden behind corporate firewalls and proxies, so that you can get some work done.

Here is an example. I have a servers than can connect to all the internal network, but you can't get to this server externally, but is has access to a proxy.

Firstly you set up it's ssh config file so that it can talk through the proxy, and then you create a reverse tunnel to a machine in the cloud. You then use autossh to manage that link, so that when you need to use it , it is available.

There are so many variables in this that covering them all is not feasible, but here is an example:

First, make sure that the ssh public keys for both servers have been put into the authorized_keys file in .ssh on the other machines. Swap public keys, in other words.

Configure you .ssh/config for the user to include the following parameters
TCPKeepAlive yes
ServerAliveInterval 270
ProxyCommand /usr/bin/corkscrew 192.168.2.1 8080 %h %p

Where 192.168.2.1 is the IP of your proxy and 8080 is the port it listens on

So when we make the connection to the cloud servers, it will use this encapsulation.

Now we create the tunnel

/usr/bin/autossh -M 29001 -f -nN -R 1102:localhost:10000 billblogs@cloud01.tangerine.co.uk

Ok, lets break the command down
autossh uses -M to specify it's keep alive port, and -f to place the job in the background.

ssh uses the -nN and -R to say this is going to be a reverse tunnel, and on the cloud server it will open port 1102 and connect it to port 10000 on the internal server running the ssh daemon that we start this job from. In other words, the sshd daemon on the internal server is listening on port 10000.

So, once this is all configured, you can go to your cloud server, connect on port 1102, and it will be as if you were sat at your desk, voila

Here is the command you would use to connect:

ssh -p 1102 billbloggs@localhost

NB You need to make these connections as secure as possible, and disable root logins and only allow keys.