Port Forwarding with SSH

For those of you unfamiliar with SSH, it allows for secure encrypted network communication and can replace insecure unencrypted utilities such as telnet, ftp, and the r-commands (rlogin, rsh, rcp). If you still use telnet please put this magazine down right now, go disable the telnet daemon, and install SSH and then continue reading.

I’m not aware of any major distribution that doesn’t ship the SSH client and server in some form, so installation should be trivial using your distro’s package utilities– if they’re not installed already. For this month’s” Tech Support” column we will use OpenSSH, a free version of the SSH suite of network connectivity tools available from http://www.openssh.org, and SSH protocol version 2. If you use a different SSH suite, or are using SSH protocol version 1, some of the instructions may not apply or may need to be modified.

Whenever you SSH from one machine to another, you are establishing a secure encrypted session. You can take this one step further with SSH port forwarding, which allows you to tunnel arbitrary TCP connections though your secured session. Port forwarding can be useful in a variety of situations, from securing remote POP3 connections to tunneling through firewalls. If you are doing the latter, make sure to be mindful of any policies your IT department may have in place. There are two kinds of SSH port forwards, LocalForward and RemoteForward. I’ll give one example of each, and will cover the two scenarios given. If you’re having problems with SSH port forwarding, the debug option (-vv) should provide you with some useful clues.

The -L flag is used to enable LocalForward functionality and will forward the given port on the local SSH client to the specified remote host and port. The syntax is -L localport:host:hostport. Let’s say you have a remote mail server that does not support encrypted POP3. You don’t have a local shell account on that mail server, but you do have an account on a development server that is on the same network as the mail server. You can use port forwarding to secure traffic from your local machine to the remote development server. Note that the traffic will travel from the development machine to the mail server unencrypted. While this is not ideal, it’s a large improvement as all traffic over the Internet will be secured.

The following command will forward port 9110 on your local machine to port 110 on the mail server, via the development server. We’re using port 9110 on the local machine instead of 110 since privileged ports (those below 1024) can only be forwarded by root. The -Nf flags will run SSH in the background, without requiring the execution of a command on the remote machine.

$ ssh-Nf-L 9110:mail.server.com:110 development.server.com

The -R flag is used to enable RemoteForward functionality and will forward the given port on the remote server to the specified local host and port. This can be used to allow access to your local workstation at work, even if a firewall and NAT are in the way. The syntax is -R remoteport:host:hostport. For this scenario, you will need sshd running on a machine that you have access to from home. From your machine at work, run the following command:

$ ssh-nF-R 2222:localhost:22 machine.you.have.access.to.from.home

Now, from home you can connect to that machine and run:

$ ssh-p2222 localhost

You are now connected to your work machine. Some firewalls may disconnect inactive sessions. In this case you can exec a ping via SSH to generate activity or set the ClientAliveInterval parameter in sshd_config to request a message from a client that has not sent data.

In addition to specifying -L and -R on the command line, you can also use a Host specification in your local SSH config file. To replace the -R example used above, put the following into your ~/.ssh/config file:

Host work-tunnel
Hostname x.x.x.x
RemoteForward 2222:localhost:22
User jeremy

You should replace jeremy with your username and x.x.x.x with the IP address of the machine you have access to from home. If you get tired of typing passwords when forwarding traffic, you can set up SSH keys, which I covered in the June 2004 column. (http://www.linux-mag.com/id/1711)

SSH port forwarding can prove useful in a variety of situations– I’ve only covered the basics. Be sure to follow any company policies and be aware of the security implications that using port forwarding may introduce into your setup. If you do that, you will find the flexibility offered by port forwarding to be extremely useful.