Sam Saffron

Recently, I had to support a rails server which is deep behind a firewall. Here I offer a somewhat sketchy account of how I am able to support it.

The IT department is in love with their brand new proxy server. They are so in love with it that they decreed that all connections to the Internets must go via the proxy server, no exceptions.

My brand new web 2.0 intranet application must also live behind this proxy server. I think it makes perfect sense, except for one minor issue. How do I support this thing? I discussed my solution with the IT department and they were fine with it. So here you go.

Corkscrew

Corkscrew: is a tool for tunneling through http proxies. Its a little bit like netcat which in turn is a little bit like telnet. It connects to a proxy and gives it your input stream in base64.

Corkscrew and ssh are friends, all you have to do is add the following line to the ~/.ssh/config file

I wanted to be able to ssh into the firewall from the internets. So I had to push port 22 on my intranet server to my public server.

The command to do this is fairly trivial, something along the lines of the following will do:

ssh -R 8888:localhost:22 public_server

Once this is done I can ssh into public_server on port 8888 to access ssh on my server which is behind the firewall.

The big problem is that ssh tunnels behind NATs and Proxies die. Death of the ssh tunnel means I no longer have remote access, which means I have to drive to the client to fire it off again. This is obviously not acceptable.

So the internet has quite a few solutions to this problem, the most popular one seems to be a tool called autossh.

This tool will restart your tunnels if they die. I set this tool up and it seemed to work fine for a day or two. But somewhere between me not configuring the tool right and the almighty proxy, autossh seemed to fail on me. So, I decided that instead of spending a week debugging this I might as well write a simple script in ruby to monitor my ssh tunnel.

Super SSH

I chucked my in progress script on github for your enjoyment. What it does is fairly simple. It forwards the ssh port to the public server and tries to connect back to itself from the public server every minute. If the connection fails it assumes something went wrong and it will restart the tunnel.

It still needs a bunch of command line switches and a fair bit of work, but it seems to be doing the job for me.

A key to getting anything along these lines to work is ensuring your ssh connection uses public/private keys for authentication. If you use ssh on a regular basis and passwordless ssh authentication sounds foreign, stop reading this and look it up on the internet. The two commands, ssh-keygen and ssh-copy-id are your friends, use them.

Working from home, jumphosts

In order to deploy my application from home I need to connect to the server behind the firewall via my public server. I can always ssh twice, but it seems like a little bit of a headache.

I wanted to type “ssh work” and have my dev box connect to the production box. I also wanted http://localhost:9999 to take me to the production web site, so I can test it.