2

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, 2.6.24.5-grsec-xxxx-grs-ipv4-32 (root@kernel-32.ovh.net). 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 127.0.0.1 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 <client.in' >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 >client.in
ls

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.

UPDATE

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.

  • 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

5 Answers5

3

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

James L
  • 5,915
  • 1
  • 19
  • 24
0

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.

Massimo
  • 68,714
  • 56
  • 196
  • 319
0

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.

http://en.wikipedia.org/wiki/Hamachi http://www.hackitlinux.com/50226711/using_hamachi_on_linux.php https://secure.logmein.com/US/products/hamachi2/download.aspx

Joshua Enfield
  • 3,404
  • 8
  • 41
  • 58
0

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

Nikolaidis Fotis
  • 1,994
  • 11
  • 13
0

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.

Bill Weiss
  • 10,782
  • 3
  • 37
  • 65