3.12. Allowing Remote SSH Through a NAT Firewall

Problem

You want to open up remote SSH administration to your LAN so you can log in remotely and access various random LAN hosts. You have the OpenSSH server running on the machines you want to remotely administer, but there is a problem—they use nonroutable private IPs, so they are all source NAT-ed to the firewall IP address. How do you get past your NAT firewall?

Solution

The simplest method uses any of the SSH rules in the previous recipe (except, of course, the LAN-only rule) without requiring any changes. SSH into your firewall, then SSH from there into whatever LAN hosts you need to get into. Your sessions will look like this example, which demonstrates logging from a remote host into the firewall named windbag, and then opening an SSH session from windbag to stinkpad:

	carla@remotehost:~$ ssh windbag.foo.net
	carla@windbag.foo.net's password:
	Linux windbag 2.6.12-10-386 #1 Mon Sep 28 12:13:15 UTC 2007 i686 GNU/Linux
	Last login: Mon Aug 21 17:07:24 2007 from foo-29.isp.net
	carla@windbag:~$ ssh stinkpad
	carla@stinkpad's password:
	Last login: Mon Sep 21 17:08:50 2007 from windbag.foo.net
	[carla@stinkpad ~]$

Using this method avoids the problem of having to write additional iptables rules.

What if you have users who need remote SSH access to their PCs, and you deem them worthy enough to have it? To use the two-step SSH login, they will need user accounts on the firewall, which you may not want to allow. To avoid this, you can set up port forwarding directly to LAN hosts. For example, you have host1 at 192.168.1.21, and host2 at 192.168.1.22. Your remote users are at 12.34.56.78 and 12.34.56.79. You accept remote SSH logins only from those IP addresses:

	# allow user@12.34.56.78 to ssh directly to work PC
	$ipt -t nat -A PREROUTING -i $WAN_IFACE -s 12.34.56.78 --sport 1024:65535 \
	-p tcp --dport 10001 -j DNAT--to-destination 192.168.1.21:22
	$ipt -A FORWARD -p tcp -i $WAN_IFACE -o $LAN_IFACE -d 192.168.1.21 \
	--dport 22 -j ACCEPT
	
	# allow user@12.34.56.79 to ssh directly to work PC
	$ipt -t nat -A PREROUTING -i $WAN_IFACE -s 12.34.56.79 --sport \
	1024:65535 -p tcp --dport 10002 -j DNAT --to-destination 192.168.1.22:22
	$ipt -A FORWARD -p tcp -i $WAN_IFACE -o $LAN_IFACE -d 192.168.1.22 \
	 --dport 22 -j ACCEPT

Then, your users simply need to specify the port number and the fully qualified domain name or IP address of the firewall to log in:

	user@12.34.56.78:~$ ssh windbag.foo.net:10001

or:

	user@12.34.56.79:~$ ssh 1.2.3.4:10002

What if you or your users need access to more than one LAN host? See Recipe 3.13.

Discussion

I like the second method because it gives the admin the most control. Handing out user accounts just for remote SSH access on your firewall is a bad idea. You should also configure the excellent access and authentication controls in OpenSSH to further batten the hatches, and consider using public-key authentication instead of system passwords. Your user's source IP addresses are specified in the rules because you do not want to leave LAN hosts open to the entire Internet, and you especially don't want them logging in from public machines in libraries or Internet cafes (keystroke loggers, anyone?).

If your WAN IP address is dynamically assigned, then you're going to collect a lot of host keys because host keys are bound to IP addresses. So, every time the WAN address changes, you'll get a new host key. Dynamic WAN IPs cause all sorts of hassles if you want to do anything other than just have an Internet connection—running services and remote administration is a heck of a lot easier on a static WAN IP address.

See Also