Script Day: SSH to a host behind a NAT

I use SSH daily to work with different remote services, and its always a very straight-forward process… unless the remote server you want to work with is on LAN somewhere behind NAT(1). When you need to access such an internal server, the only option is to SSH into the firewall(2), and then SSH again to your server of choice.

But there’s a better way, and you don’t even have to fiddle with the firewall server!

(this is not actually a script, though minimal text editing is required)

The solution is actually quite simple: set up an alias in your .ssh/config file that you can use to call the remote server when you are outside the LAN (if you are inside the LAN its better to access it directly), and for that alias we will set up a ProxyCommand that will tell SSH to first access the firewall server and open a tunnel to the target LAN server.

It looks like this:

Host remote-alias
ProxyCommand ssh firewall-user@firewally-server nc lan-server 22

This set up works best if your access to the firewall-user account is without password or passphrase (using an SSH private key that is either without passphrase or already loaded in the agent), then the login is as streamlines as a direct access – but the worst is that you’d need to type in two passwords.

Enhanced by Zemanta

  1. router that does Network Address Translation so the servers address is not accessible from outside the LAN []
  2. or some other server that has legs both inside and outside the LAN – I’m using a DNATed server, what most off-the-shelf routers incorrectly call “DMZ“ []

4 Responses to “Script Day: SSH to a host behind a NAT”

  1. Assaf:

    Haven’t you heard of ssh key and key forwarding ?

    I use it all the time and it saves on typing the passwords.

    i

  2. Oded:

    When you want to connect from A to C through B, SSH agents and key forwarding don’t save you the need to type in the command to ssh from B to C – it just saves you the need to manipulate more keys if both C and B can be logged into using your key chain on A.

    What I’m trying to solve is how to seamlessly ssh from A to C without starting a shell on B and typing commands there. The proxying is transparent enough that if you later login to B, you won’t see your proxy command in the shell history (which may or may not be useful to you).

    Also, if this is something that people do a lot in your organization, it will be better to set something up on the firewall itself instead on relying on each person configuring proxy commands on their system.

    • Assafr:

      I disagree, I have the setting in my .ssh/config and the only thing I need to type on A is ssh C and the session via proxy B is established with no need to type anything on B or C.

      This is very helpful when I work with cssh as I have it installed on A (my desktop) and then open multiple session via proxy and do not need to type passwords.

      And yes the whole Team is doing this – Both of us! No need for a dedicated appliance (or server) for that many people.

Leave a Reply