ssh tunnels

I love ssh tunnels.

Working in an office, with a super strict data center, they make my work so much easier.

Basically an ssh tunnel is a way to put a local port in a remote server, and vice-versa.

Scenarios it might be useful:

1. You have a bastion/jump server that you need to connect to do EVERYTHING. It makes sense to just have one main ssh session established, and just connect with the same dynamic proxy tunnel to all the rest of the servers stepping through, without having to connect again each time.
   
   Situation:
   local machine TO jump server
   local machine TO jump server, jump server TO server only accessible by jump server1
   local machine TO jump server, jump server TO server only accessible by jump server2
   ...
   (above, you need to ssh to the jump server, and from then, ssh to the remote server, every time.)
   
   Solution:
   local machine TO jump server
   local machine ( through tunnel ) server only accessible by jump server1
   local machine ( through tunnel ) server only accessible by jump server2
   ...
   (above, you just open one session to the jump server. And then can ssh directly from your local box to the remote servers through the tunnel)
2. You can ssh from your local machine TO a server, but not the other way around (due to firewall, being behind a router, etc)
   
   Situation:
   local machine TO remote server = OK
   remote  server TO local machine = NO
   
   Solution:
   local machine TO remote server (remote forward:9001 to localhost:22)
   remote server TO remote server port 22 (=local machine's ssh port = local machine)
3. You want to share a port/server only accessible from the office, to a remote server. Let's say, your intra network's GIT server, to a server. Or your mail server, local printer, etc.
   
   Situation:
   local machine TO intra git = OK
   remote server TO intra anything = NO
   
   Solution:
   local machine TO remote server (remote forward RANDOM_PORT to intra git server's SSH PORT)
   remote server TO remote server's RANDOM_PORT (goes through your local box, and to intra's git server)
4. Debugging your flask DEV env on port 5000, and your firewall doesn't let you access it directly.
   
   Situation:
   local machine TO remote server's port 5000 = NO
   local machine TO remote server = OK (ssh)
   remote server  TO remote server's port 5000 = OK
   
   Solution:
   local machine TO remote server (local forward 5000 to localhost:5000)
   local machine TO local machine's port 5000 ( = remote server's port 5000)

These are just some simple examples.

You can also kind of nest them! One ssh tunnel to another, and another... and sometimes it gives you a bit of a headache.

My .ssh/config file is huge due to this, but it beats the alternative of not being able to debug a flask development instance live with your browser, for example.

What is dynamic/local/remote forwarding?

In short:

Dynamic tunnels act as SOCKS servers. This means you can ssh connect with the nc command sending all the stream directly. When you set up dynamic forwarding for a host, your local machine dynamic forwarding port will act as a SOCKS server.

local forwarding = the port will be on your local machine, pointing to somewhere in the remote server

remote forwarding = the port will be in the remote server, pointing to somewhere on your local machine

Easy, right?

So, how to do you this?

I think you can do this in windows terminals too, and even macs. But This is GNU/Linux blog, so I'll be talking only about the ssh command and its config.

You can do all this with arguments to the ssh command, but I was never able to remember those. So I just edit my ~/.ssh/config file for all these settings, and that's the way I'll be introducing.

All settings below will be in your local machine's ~/.ssh/config.

Let's create a dynamic tunnel

Host some-jump-server.net
  # these two aren't really necessary, I just like them
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  DynamicForward 5555

So, you just "ssh some-jump-server.net" in one terminal, and keep that session open.
To access a server only accessible from the jump server, you just add that server to your ~/.ssh/config, defining it as a server that needs to go through that proxy, or you can also like create a script for the same purpose.

This is how I'd register the server:

Host some-server.my-subnet
     ProxyCommand nc -x 127.0.0.1:5555 %h %p

Then you just "ssh some-server.my-subnet". And in one ssh, you should be accessing the remote server.
You'll probably be needing an ssh agent if you plan to do this though, but that's a topic for another post.

Also, notice you don't need to add hosts one by one, you can set complete sub-domains, or just "all" with the "*" wildcard (next to the "Host" keyword). "*.my-subnet" for example, would set this dynamic proxy port for all servers you try to ssh that end with ".my-subnet".

Let's try a localforward

Local Fowards open a port in your local machine, to somewhere pointing on the remote server.
Let's use the flask development port (5000) for example, that you can only see in your server, and can't access directly from anywhere else.

Host some-server-with-my-flask-dev.my-subnet
     LocalForward 8559 localhost:5000

So, now you can just put your in local machine's browser the url http://localhost:8559/, and you'll be accessing your remote host's port 5000, yay. No need to proxy or anything, just ssh.

And, let's try a remoteforward

The last one, remote forward, opens a port in the remote server, pointing somewhere in your local machine.

Host some-server-that-needs-intra-stuff.my-subnet
  # pointing your local git server for example
  RemoteForward 5757 192.168.11.1:7999

  # or to your tiny proxy http proxy, in case you need to access intra web
  RemoteForward 8999 localhost:8888

So, if you ssh to some-server-that-needs-intra-stuff.my-subnet, you'll be able to see with "netstat -atn|grep LISTEN" for example, that the ports 5757 and 8999 are open. And they'll be pointing to your local machine's 7999 and 8888 ports respectively. In this example, they're your local git server, and http proxy. So virtually, you could be accessing the same INTRA web from a DC that shouldn't have access at all! yay! Welcome to the wonderful world of security risks as well, be careful!


In conclusion, ssh tunneling is fun. Remember you can also have multiple remote and local forwards in each host block, and you mix them as well. It can be quite a mess! But sooo damn useful.