Start Reverse Tunnel on boot using autossh for Debian 7

As usual, most of the how-to guides out there are too brief (I’m guilty) or apply to other distros:

This works on Linux Debian 7 all-around, and this is a complete how to. It works. You just have to follow a very long thread. No A.D.D. here!

We will create a Persistent Reverse SSH Tunnel between 2 machines using autossh. We will be using our desktop as a third machine.

This is convoluted, but then good things are seldom easy.

If you are not very experienced with Private/Public key GPG encryption, doing reverse tunneling is doubly confusing. Not only is a reverse tunnel a convoluted concept, then you also have the equally convoluted issue of Private/Public Key Encryption to deal with. So one-issue-at-a-time-and-slowly;

It may be helpful to draw (on paper) a diagram;

1) Our Hidden machine is the one behind the firewall (behind NAT) – you know this machine or you would not be reading this. Our Hidden machine will call and create a tunnel using a known server. That server is called our Remote machine.

2) Our Remote machine is the one that will be contacted by the Hidden machine. The Remote machine is typically a (middle-man) server that has a static IP address. The static IP is the key. The Hidden machine needs to reach out and create the tunnel using a known static IP address or this does not work. The connection is built in reverse. Thus why it’s called “a reverse tunnel”.

3) Our Desktop machine is probably/also behind a firewall and will login to the Remoter server normally. Then we use the Remote Server to login to the Hidden machine that is waiting for our login.

Each machine should have different usernames (for your first go at this). Its not mandatory, but it cuts down on the confusion. Check?

Now the tricky part is to get the appropriate keys placed on all the machines before hand. That is because we can’t have passwords/login prompts interfering with one machine logging into the other. Such a pause causes everything to hang…

Ordinarily, no problem. But this is a real problem concerning the Hidden machine. The Remote machine key needs to be found in /home/username/.ssh/authorized_keys of our Hidden machine. But how do we do that if the Remote machine cannot call the Hidden machine? Its called manual labor!

Assuming you have completed the creation of all key-pairs using default setup options;

1) Copy from the Hidden machine, it’s GPG public key to the Remote server;

2) Copy the Remote keys to your Desktop somehow. This is probably a few-step process. I first save the authorizes_keys into my Remote machine home directory, then Rsync them back to the Desktop machine.

sudo cp -f ~/.ssh/authorized_keys ~/

Now get the authorized_keys file into the Hidden machine’s /home/username/.ssh/authorized_keys

Others may give you more concrete methods to do this “messy” business. But that’s just normal Linux stuff beyond the scope of this post. Therefore, you will have to manage the permissions and transport of the file yourself. I use Rsync to move files and preserve permissions. In the end, just be sure your permissions are set correctly or none of this will work.

Monitor the Remote machine

sudo tail -f /var/log/auth.log

sudo watch netstat -plunt

The assumption at this point > You are already logged into the Remote from your Desktop using SSH on a DIFFERENT PORT. I will not be including further instructions as that is beyond the scope. I assume you are knowledgeable enough to setup a standard SSH session between these two machines.

tail -f /var/log/auth.log will tell you what went wrong
netstat -plunt will show you the established connection (the tunnel)

If all goes well, you should see (on the Remote machine using netstat) the port and username where SSH is waiting for you to login from the Remote server to the Hidden machine:

Search Engine Leads

SELeads.com is my webmaster notebook. I hope you found what you were looking for. In appreciation you might Google+ or a link-back is even better. If you want a backlink, put it in a comment and I’ll reciprocate.