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 am trying to make it possible to control a shell on a linux box behind a router which is not under my control.

My first idea was to make the client (the box behind the router) to ssh to a server under my control and forward the local ssh port, periodically from cron, like this:

client$ ssh -L 40000:localhost:22 root@server

It works with my private, less secure server, but fails with the customers server, which is a grsecurity hardened CentOS, ( I do not know a thing about grsecurity and particularly not about how it is configured on this server. The AllowTCPForwarding option is sshd_config is on its default, which is supposedly(as of RTFM) 'yes', and ssh -v tells me

debug1: Local connections to LOCALHOST:40000 forwarded to remote address localhost:22
debug1: Local forwarding listening on port 40000.

but all I get when trying to ssh back to client from this server is 'Connection refused'.

Next idea:
On client:

client$ bash -i <in >out 2>err &
client$ ssh root@server 'cat <' >in &
client$ ssh root@server 'cat >client.out' <out &
client$ ssh root@server 'cat >client.err' <err &

On server:

server# cat client.out &
server# cat client.err &
server# cat >

All of these, {client.,}{in,out,err}, are named pipes, made with mkfifo. But somehow the ssh does not work this way for me, nothing ever gets over net. This works partially with normal files (not named pipes) and tail -f. But than I have the feeling this is not how you accomplish this. And the worries about plain files getting too big, and overwriting... it just does not seem pretty.

Any ideas? I have root on customers server, but would prefer not to install kernels and wreak havoc.


Clarification: The client box will be installed by the customer on some distant location behind a router, of which neither I nor the customer has control. So, no port forwarding or dynamic DNS on the router. Just a plain linux box with a private IP somewhere on the net. The first idea I pictured would work out with a server less secure than the customers server. I am supposed to use the grsecured one. I am able to ssh from the customers grsecured server to other locations, so it is not an iptables problem. I am also able to open listening ports (with nc -l) and to connect to them.

I am connecting from the client behind a router to the server, forwarding some high server port (e.g. 40000) to the ssh port on the client, so I can first ssh from home to the server an then ssh from the server to the client. As i said, the client is not in my network and is behind a router which is not under my control.

I am not ssh'ing back home, the client is not the machine I start this wonderful journey from. Home, server and client are on three distinct networks.

share|improve this question
why not just forward port 22 through the firewall / router to the machine and set up a ssh server ?? what do you mean by "still to be installed" ? - does this box have no o/s on it ? – Sirex Aug 23 '10 at 13:16
up vote 3 down vote accepted

I think you're doing the SSH tunnel the wrong way around, so you're effectively tunnelling from the client you're trying to access to the open server, instead of the other way around. You won't be able to use the -L as you can't connect to the client to establish the tunnel.

The way forward, if GatewayPorts is on in sshd_config on the server under your control, is to use a reverse tunnel, so for example: ssh -N -R 40000:localhost:22 user@server_under_your_control

share|improve this answer
FACEPALM yes I was doing it wrong way around. Thank you. – fungusakafungus Aug 23 '10 at 17:45

Just a tought on your first solution: have you checked IPTABLES is not blocking your connections? Maybe you just need to allow such traffic in the system's firewall.

share|improve this answer
I could have easily overseen that, but no, firewall is not blocking the connection. – fungusakafungus Aug 23 '10 at 17:40

You could also Try Hamachi. I use this for the same purposes. The windows version is the primary line of development, but there is a Linux one floating around as well. I'll find a link when I have more time and edit. The guide below might actually link you to it.

share|improve this answer

What James said works perfect with static IP. if he doesn't have one , he must use a service (Let's say dyndns) that will indicate his ip at every time.

As an example, ssh -R blahblah user@thisIsMyIp Then you must make a script that will check if the connection is up, and if it isn't then you must execute the command above

share|improve this answer

You might want ssh port forwarding the other direction. Namely:

client# ssh -R 40000:localhost:22 clientLogin@yourServer

With some SSH keys and whatnot, as well as a wrapper to restart it if it drops. That will let you SSH to yourServer:40000 and get a shell on client.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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