2009-11-15

We've covered tunneling before on HiR. I even wrote a little about reverse tunneling in my quick-and-dirty tunneling howto. This time, I'm building a setup to make an always-on reverse tunnel with a cron-powered watchdog script. I've even coded a cron watchdog before, but this way is less hackish, in my opinion.

Here's what's needed to make it work:

A Linux/BSD/Unix system on the inside of your target network that's capable of SSH-ing out to the Internet (even if via strange ports)

An SSH server you control on the Internet. This can be at home, or elsewhere

The reverse tunnel can handle pretty much any protocol. To a squid proxy, for example. I'll be using SSH to reverse-tunnel SSH, though, to allow SSH access to a server behind a firewall that I do not control. Here's how it'll work:

Cron will run a script on the server on the inside. This script will check to see if the SSH tunnel is working properly. If it's not (or if it hasn't been started yet), it will start the reverse tunnel.

Here's the script, which I put in /usr/local/bin/rtunnel.sh. Obviously, you need to edit the first 4 variables to reflect your environment.

#!/bin/shUSERHOST=axon@somewhere.labs.h-i-r.net # Login and External systemRPORT=22 # SSH Listener port on your external systemFPORT=1337 # Port that will be opened locally to tunnel SSHCONN=localhost:22 # SSH Listener on the system behind the firewall

Then uses pgrep (ps command with grep functionality) to see if it's up and running, and tries to ssh to the outside system, using netstat to check the status on that end. If either of those fail, the process is killed with pkill (pgrep, with kill functionality) and restarted.

And then I put the entry in root's crontab, to run every 5 minutes:

*/5 * * * * /usr/local/bin/rtunnel.sh

In my implementation, the firewalled host (An OpenBSD box) is connecting to a Ubuntu desktop system at my home. I can just log into it, then use the tunnel on port 1337, using the -p [port] option.

Please use the sendbug(1) utility to report bugs in the system.Before reporting a bug, please try to reproduce it with the latestversion of the code. With bug reports, please try to ensure thatenough information to reproduce the problem is enclosed, and if aknown fix for it exists, include that as well.

-bash-3.2$

If the connection times out or fails for any other reason, the remote end should re-spawn the connection in the next 5 minutes. If you've waited, and don't get a response, something else might be amiss. DNS rules, a network admin that's blocked you, etc... You can try switching the port SSH runs on

The one problem I've had is that occasionally the session will be alive, the port will be forwarded, but I can't get it to log in. It just hangs then times out. If this happens, I use lsof on my workstation to find and kill off the process that's listening on the TCP port I am using for forwarding.

We've covered tunneling before on HiR. I even wrote a little about reverse tunneling in my quick-and-dirty tunneling howto. This time, I'm building a setup to make an always-on reverse tunnel with a cron-powered watchdog script. I've even coded a cron watchdog before, but this way is less hackish, in my opinion.

Here's what's needed to make it work:

A Linux/BSD/Unix system on the inside of your target network that's capable of SSH-ing out to the Internet (even if via strange ports)

An SSH server you control on the Internet. This can be at home, or elsewhere

The reverse tunnel can handle pretty much any protocol. To a squid proxy, for example. I'll be using SSH to reverse-tunnel SSH, though, to allow SSH access to a server behind a firewall that I do not control. Here's how it'll work:

Cron will run a script on the server on the inside. This script will check to see if the SSH tunnel is working properly. If it's not (or if it hasn't been started yet), it will start the reverse tunnel.

Here's the script, which I put in /usr/local/bin/rtunnel.sh. Obviously, you need to edit the first 4 variables to reflect your environment.

#!/bin/shUSERHOST=axon@somewhere.labs.h-i-r.net # Login and External systemRPORT=22 # SSH Listener port on your external systemFPORT=1337 # Port that will be opened locally to tunnel SSHCONN=localhost:22 # SSH Listener on the system behind the firewall

Then uses pgrep (ps command with grep functionality) to see if it's up and running, and tries to ssh to the outside system, using netstat to check the status on that end. If either of those fail, the process is killed with pkill (pgrep, with kill functionality) and restarted.

And then I put the entry in root's crontab, to run every 5 minutes:

*/5 * * * * /usr/local/bin/rtunnel.sh

In my implementation, the firewalled host (An OpenBSD box) is connecting to a Ubuntu desktop system at my home. I can just log into it, then use the tunnel on port 1337, using the -p [port] option.

Please use the sendbug(1) utility to report bugs in the system.Before reporting a bug, please try to reproduce it with the latestversion of the code. With bug reports, please try to ensure thatenough information to reproduce the problem is enclosed, and if aknown fix for it exists, include that as well.

-bash-3.2$

If the connection times out or fails for any other reason, the remote end should re-spawn the connection in the next 5 minutes. If you've waited, and don't get a response, something else might be amiss. DNS rules, a network admin that's blocked you, etc... You can try switching the port SSH runs on

The one problem I've had is that occasionally the session will be alive, the port will be forwarded, but I can't get it to log in. It just hangs then times out. If this happens, I use lsof on my workstation to find and kill off the process that's listening on the TCP port I am using for forwarding.

HiR Featured Columns

HiR Tools

HiR Categories

About HiR

HiR is what happens when 1990s-era e-Zine writers decide to form a blog. Most of us hail from the Great Plains region of the United States.

Ax0n, HiR founder and editor-in-chief is an information security specialist currently working in the luxury goods industry.

Asmodian X joined HiR in December 1997 and currently works as a web developer and SysAdmin in the education industry.

Frogman has been on board since May 1998 and has many technical passions. When not experimenting with obscure hardware, he can be found leaping from one rooftop to the next, making the world his office.

TMiB has also been helping since 1998. Also our resident Physicist and go-to guy for xkcd jokes we don't get, The Man in Black currently works in the Internet industry in an east-coast data center.