Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know a number of vendors that sell network/server appliances, that have a support button, that once pressed, setup an SSH support tunnel back to the vendors main servers so the support technician can connect directly into the appliance and troubleshoot it.

I would like to set this up, but without the need to press the support button. I want to deploy laptops at remote locations that then automatically call back to a master on a regular basis, and reestablish connections if the box reboots, or the remote network drops connection for a short while. (both ends are Linux boxes)

Basically I want to deploy temporary Zenoss/Cacti monitoring servers in customer environments, but I do not want to have to punch holes through their firewalls, or deal with their site specific VPN settings.

Does anyone know of any scripts or ssh daemons that help set this functionality up?


locked by HopelessN00b Jan 21 '15 at 22:30

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as off-topic by HopelessN00b Jan 21 '15 at 22:29

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

looking at this from the customer's point of view that's one massive security hole you're tying to create in their networks. I hope you have their permission do do this. – John Gardeniers Mar 22 '11 at 11:13
Please don't get me wrong, I totally recognize (and agree) that this approach is completely unacceptable for most (98%) businesses. The actual situation that this is being considered for is a small (2) person private business that doesn't have the budget for any internal servers (which is why I'm deploying my own laptop), and a very rudimentary firewall/gateway/nat device. To top it off, the existing network is a dual layer of private IP NATS (first being the ISP device with no bridged mode or port forwarding, and the second being the internal router). – BrianH Mar 23 '11 at 7:41
This approach is not to far removed from current business models of people like TeamViewer, LogMeIn, or BacktoMyPC. All of which support unattended remote sessions by establishing an outbound connection to a master server, thereby allowing the user or tech to connect in without having to worry about firewall configurations. This is not something I intend to rollout without making sure the "Master PC" is severely locked down. I'm even thinking about some method of having the slave device first look for a file/flag/variable (on the master server) before opening up the SSH tunnel. – BrianH Mar 23 '11 at 7:44
@Brian, I realise the similarity to other methods (we use TeamViewer ourselves) and also that sometimes it's the way things must be done. It's just that I believe the other party should be aware of possible problems and approve it before it's implemented. – John Gardeniers Mar 23 '11 at 7:49
@John, again, I totally agree. And yes, they are well aware of the current implications and possible security breaches. Luckily, this is only being deployed for about 1 week while we try to troubleshoot network connectivity issues. – BrianH Mar 23 '11 at 8:04
up vote 4 down vote accepted

Try autossh. It's doing exactly what you are asking for, assuming you setup public key authentication (otherwise you must manually enter password each time).

Quote from autossh web page:

autossh is a program to start a copy of ssh and monitor it, restarting it as necessary should it die or stop passing traffic.

If you want to start it automatically, you can use crontab. Run crontab -e and add

@reboot /usr/local/bin/

or just

@reboot autossh username@host <other ssh options here>

Caveat: autossh do not start if first connect fails (network is not up / resolving is not working). Workaround: put something like this to

while true; do
  autossh username@host -M 12313 -R...
  sleep 15

This way, if autossh exits for some reason, it's restarted later on.

Also, autossh default connection polling isn't happening really often, you can control it with AUTOSSH_POLL and AUTOSSH_FIRST_POLL variables.

Funny enough, I came across autossh just after making this initial post. The only part I wasn't sure about was how to respawn the AUTOSSH session if the laptop was rebooted (power outage or such). I thought putting it into the /etc/inittab would work, but it turns out Ubuntu has done away with the inittab and replaced it with their own system "upstart" (which I'm now looking into learning). – BrianH Mar 23 '11 at 7:47
@BrianH: I added info on how to start it automatically using crontab – Olli Mar 23 '11 at 8:51

but I do not want to have to punch holes through their firewalls

So what it boils down to is that you're trying to bypass existing security mechanisms. Not exactly very ethical. Why not tell them how their firewalls should be configured.

I've previously used ppp over an SSL tunnel (using stunnel, but ssh is just as viable, and most other vpns would work too) to map remote devices into a network. I'd set it up to run as a sysV initscript but running from upstart or DJB's daemontools is probably a more senible approach.

Not really an option (see my updated comment on the original post). – BrianH Mar 23 '11 at 7:43
I meant to say the FW thing is not really an option (see my updated comment on the original post). But I just came across the upstart part, so that looks promising (thanks). – BrianH Mar 23 '11 at 7:59

Surely you have the permission to do such a thing? Where I work that would be a blatant violation of the security policy.

Anyways, if you're going to have just a handful of boxes, you can do it without any external applications. Just set up public key authentication to the "support" server and add something like this to crontab on the laptops:

@reboot ssh -R 65000:localhost:22

(Obviously using a different port for different machines, the next laptop could use port 65001 instead etc.)

Now when you ssh to localhost on port 65000, you're connecting to the laptop's port 22.

And when there's connection interrupt (let's say: firewall reboot -> TCP states are lost -> connection breaks), how's reconnect handled? – Olli Mar 23 '11 at 7:37
Well, you could start a shell script like while true; do ssh -R 65000:localhost:22; sleep 30; done? – jho Mar 23 '11 at 7:40
Wouldn't that spawn multiple sessions? (or does ssh recognize a preexisting session and drop the new attempt?) – BrianH Mar 23 '11 at 8:01
@Brian H: ssh will not fork or in any other way detach from the current terminal, so the script will stay waiting there as long as the connection is alive. When the connection dies, it sleeps 30 seconds, tries ssh again, if it times out, sleeps another 30 seconds, and so on. – jho Mar 23 '11 at 8:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.