SSH tunnel into a DMZ creating a path back home

Diagram of JMX over SSH into a DMZ

There are already many guides on the internet about how to set up SSH tunnelling [1][2]. This one isn’t nearly as detailed as some, but it has one thing going for it: a picture! We all love pictures.

It’s really easy. It’s a one-liner.

Motivating use cases

I’m running a service in a DMZ on port 1234. I want to access this from my desktop in the internal network without opening another port in the firewall.

This is all required for accessing JMX on a Java process running in the DMZ. JMX over one tunnelled port turns out to be more complicated; there’ll be another post about that.

Prerequisites

We’re going to assume that a competent sysadmin set up the DMZ. This means that

We shouldn’t need to change any of the firewall or iptables setup.

How can you tell if SSH TCP forwarding is enabled? You might not need it anyway, but if the below doesn’t work, get verbose logging with the -v switch and look for open failed: administratively prohibited. You’ll have to get this enabled on the host in the DMZ. Persuade your sysadmin that this is ok by suggesting that they use iptables rules to block all ports to which you don’t need access from outside the host, including 1234.

We’re going to set up the tunnel on a host in the internal network, to which the client has access. (We’ll use a port on the app-server that’s different to the target port in the DMZ, just for clarity.)

Get digging

This is the magic beans:

ssh -f -L app-server:1235:127.0.0.1:1234 -N user@web-server

This says:

That’s it.

Caveats

Obviously I take no responsiblity for your web security.

If an attacker gets a shell on your web server then they’ll have access to the service whose port you’ve forwarded, because they can connect directly to it. Though if they get that far maybe you’ll likely have bigger worries anyway.

You could consider running the tunnel only when you actually want access to the management agent, and killing it when you’re done.