SSH Tunneling

From time to time, everyone has to deal with IT guys bizarre security habits. Among them, one of the most annoying are

• the so-called “security by obscurity” or “security through obscurity” practice of change default service ports
• adding multiple layers of supposed security instead of rely on one secure protocol

Regarding the first one, I will try to contact my old “Computer Security” professor of the M.Sc. course to give some more details. In the meanwhile, you can read the Wikipedia page or just use a web serach engine.

Port forwarding

You can have a look of what a tunnel is in the official ssh page.

Suppose you have a REMOTE_MACHINE_A you want to login or use or whatever, but that machine is in a remote network you can not access. But, you have accesso to REMOTE_MACHINE_B behind a firewall with only the port XXX open. What you can do is setup a tunne through the servers, consisting in successive jumps that will allow you to enter to the REMOTE_MACHINE_A like a charm.

What you have to do are just two “local” tunnels.

On your machine, the one you are working, create a local tunnel to the machine where you have access. The ports at this moment are not important, let add use a “port shift” of 10000 (or 10100) method to denote that if we want to use port 22 of the final machine, now we’ll use 10022 or 10122. Last thing, localhost is the same as 127.0.0.1 ;-).

Create tunnel from port localhost port 10022 to REMOTE_MACHINE_B port 10122. Use USER@REMOTE_MACHINE_B to access the remote machine. In this way, every local connection to port 10022 will be forwarded to port 10122 on the remote machine, automagically, encrypted.

1. ssh -L 10022:localhost:10122 USER@REMOTE_MACHINE_B

In this way, if you have a service listening to port 10122 on the REMOTE machine BUT that port is hidden with a firewall, now on your LOCAL machine machine you can log to the LOCAL machine on port 10022 without saying anything about the REMOTE machine, the tunnel will do the grunt work.

Iterating this procedure you can add more “jumps” too. Example: want to connect to the port 22 of REMOTE_MACHINE_A?

1. LOCAL MACHINE: ssh -L 10022:localhost:10122 USER@REMOTE_MACHINE_B
2. MACHINE-B:     ssh -L 10122:localhost:22 USER@REMOTE_MACHINE_A

then, access to the local machine BUT to the port we specified in the first tunnel and ssh will forward the request through REMOTE_MACHINE_B directly to REMOTE_MACHINE_A, even though for your ssh agent you’re connecting to the LOCAL port.

3. LOCAL MACHINE: ssh user@localhost -p 10022

that’s all folks.