Double tunnels to help a colleague in distress
Fri 18th Feb 11
The Scenario
You are stuck in the office slogging away to get a pile of reports finished while a colleague is on site having fun popping boxes but you get a call, he has come up against a box he is having trouble with and needs your help. He is on site and has full outbound Internet access but as typical has no inbound access to his machine. You try to explain a solution but wouldn't it be much easier if you could just jump onto his box and show him?
The Setup
All you need for this is a way for your colleague to be able to make an SSH connection to your machine so make sure your firewall is setup to port forward an external port through to your machine. He then connects to you with this command:
ssh -R 2222:localhost:22 robin@1.2.3.4What that will do is to SSH from his machine to yours and push his port 22 through to port 2222 on your machine. Why 2222? For two reasons, one, unless you are root then you can't open a port less than 1025 and second you are probably already running your existing SSH server on port 22 (even if it is different externally for obscurity).
You can now SSH to his machine by connecting to your own on port 2222:
ssh -p 2222 gav@localhostAnd there you have it, you are now connected to his machine as him, why as him? Because if you now use the screen command (See Hak5 for an intro) and he also runs screen with a -x then you will both be connected to the same console so anything you see he sees, and vise-versa. A cool trick to allow collaborative working or training.
Browsing Web Apps
As an extension to this, imagine he found a web app that he wants you to look at and it is on 10.1.1.2, there are two ways you can do this, he can create a new tunnel, this time pushing port 80 from that machine to you with:
ssh -R 8000:10.1.1.2:80 robin@1.2.3.4or you can use port forwarding the other direction by creating another connection to him:
ssh -L 8000:10.1.1.2:80 gav@localhostIn both these situations you would then browse to localhost:8000. If the web server was using vhosts then simply edit your /etc/hosts file and make an entry with the required domain name mapping to 127.0.0.1 and now browse to vhost.name:8000.
Obviously this can be used to forward any ports, ones I'd typically look for are remote desktop and databases but anything goes.
Conclusions
This is a nice way to allow a user on the outside to become a user on the inside. There are other ways to achieve this but it is fairly simple once you get your head around which port numbers go where and as all the data is encrypted you have a nice secure channel to work on whatever needs doing.
If you find that port 22 outbound is blocked try changing your own SSH server to accept incomming connections on port 80 or 443, a outbound rule that simply checks for port numbers would allow this traffic through however it may still be blocked if packet inspection is being performed.
Credits
Thanks to Gavin for the inspiration for this post and for helping test things worked as expected.
