Friday, February 25, 2011

Reverse tunneling

If the server is behind a router you can still connect to the remote server through a thing called 'reverse tunneling'. For this you have to execute a few commands from the remote system (remote system is the server). Since the router will not allow incoming packet from the local system (local system is the one which is the client) unless you made a 'tunnel' from the remote one.
Now comes the concept of port forwarding. Here, a certain port on the server is 'forwarded' to the local system, the local system can uses this port on itself (I.e localhost) as if this port is on the the remote system. Suppose port x is forwarded, then I can -
I.e I'm using x port as if it's on the remote computer, but actually I'm using localhost for it.
This port x will actually be mapped to the port on which sshd listens on the remote system.
Before you choose the port x, ensure it's not used by anyone, else port forwarding will fail.
The -R option allows you to make a reverse tunnel from the remote system, thus do the following to make the tunnel -
ssh -R ::: @
on the remote system.
example -
ssh -R 1009:localhost (or the computer itself):22
And in the client -
ssh -p 1009 remote_user@localhost
In effect this's like -
ssh -p 22
It's useful to add the -N option also, this will avoid the server from to execute a command on the host.
Another option is -T. This will disable the pseudo terminal, that is it will make no relations to the terminal of the host system, and so it will not even be able to execute commands.
If you also specify the -n option, it'll ignore all inputs from stdin.

Chrooting user in SSH (OpenSSH_5.8p1-hpn13v10)

OpenSSH has this feature (on the server side) of chrooting users to a specific directory after they log in, that way you can ensure the users dont have access to your data. Useful when reverse tunneling.

First, you need to make a directory in which you can chroot using chroot... i.e you need the bear miminal, usually mount binding /bin and /lib64 (x64) or /lib (on x86) readonly will do so (I'm not sure about x86). Assuming /home/chroot is this directory -

mount --bind /bin /home/chroot/bin

Same for /lib(64)

Try chrooting into /home/chroot, it should work. Since you're using the libraries and executables in /home/chroot/* will be used for the by, even by SSH.

Next you need to create/modify a user which ssh will chroot to; notice that the files in /home/chroot needs to be used for this, not those in /. While creating/modifying the user, you need to take a note that the paths will be relative to /home/chroot NOT the usual way. i.e. if you're specifying bash as the default shell for the user, it will not be /home/chroot/bin/bash, but /bin/bash, thus when ssh chroots the user, it will use /home/chroot/bin/bash and not /bin/bash. Sounds confusing.

Now let's make a home directory for the user (optional, i.e you can specify / as the home directory)

mkdir /home/chroot/ch_root

Make or modify a user (I'll modify here) -

usermod -s /bin/bash --home /ch_root ch_root

Notice -- in the server /ch_root does not exist, but in /home/chroot, it does; this is what I meant to say -- paths are relative to /home/chroot and not /.

Now add the following directive to /etc/ssh/sshd_config -

ChrootDirectory /home/chroot

Restart ssh, ssh using ch_root, and the user will be logged in to a chrooted jail in /home/chroot.