Rate this page del.icio.us  Digg slashdot StumbleUpon

SSH Port Forwarding

by

SSH (Secure SHell) is well known to Linux administrators as the de facto method for connecting to other systems. SSH long ago supplanted other connection methods because it strongly encrypts the connection between the hosts, ensuring that passwords and any transmitted data are safe from prying eyes. On Fedora® and Red Hat® Enterprise Linux® systems, and many other Linux distributions, the OpenSSH suite provides the programs for this purpose. An administrator typically runs SSH to login to another system, often to run a shell on the remote host and issue commands. SSH, however, has many extra tricks up its sleeve beyond simply securing a connection.

Table of Contents

Introduction
Local Port Forwarding
Secure Proxying
Service Administration
Remote Port Forwarding
A Remote Desktop Assistance Trick
Conclusion

Introduction

If you are relatively new to using SSH, this article will show you some useful tools for securing communications other than simply logging in to a remote host. If you have a login on another system, you can use SSH to securely route other traffic in an almost endless variety of other situations. One of these capabilities is called port forwarding.

IP Networking for Newbies

In Internet Protocol (IP) networking, any connection between two hosts is made from a port number at one host’s IP address to a port number at the other host’s address. Ports range from 0-65535, and some numbers are usually claimed by particular services. For instance, port 80 is typically used by a web (HTTP) server, and port 22 is typically used by a SSH server. You can see a list of well-known port numbers in the /etc/services file. Port numbers under 1024 are usually not available for users other than the administrator.

SSH port forwarding, essentially, is the art of causing a port from one host to appear on another, using a connection through SSH. Port forwarding can accomplish several goals at once, but one of the most compelling reasons to use the technique is that traffic to the forwarded port is encrypted.

Local Port Forwarding

When you forward a port locally, you make a port from the SSH server (the host to which you are connecting) available on your local machine (the host on which you’re running the ssh command). A port on the remote machine which would otherwise be unavailable to you for reasons of firewalling or other controls can be used just as if it was your local machine’s port. This port is presumably then available to other programs on your local host, outside the SSH session. That may seem a little confusing, but the following examples will hopefully give you a clearer understanding of how this technique works.

Secure Proxying

Imagine a situation where you need to conceal your web browsing traffic. Certainly many nefarious reasons for doing this come to mind immediately, but how about a legitimate one? Perhaps you are an on-site consultant and you don’t want your employer to know you’re Googling for an answer to a particularly difficult problem. Or maybe you’re visiting your company’s time registers from off-site.

If you have a remote host, say in your home office, that uses a squid web proxy, and is reachable by SSH, you can easily use local port forwarding to augment SSH with a secure proxy channel. Assume your remote host in the home office is known on the Internet as fedora1.mydomain.com. Let’s assume your web proxy at your home office, the host called proxy, uses port 1080; it need only be available to machines inside that network. Let’s further assume that you’re sitting inside the headquarters of IT sector giant example.com, at a host called codemonkey1.example.com.

To set up port forwarding in this case, issue this command:


ssh -L 1080:proxy:1080 username@fedora1.mydomain.com

At this point, you can set your web browser to use the proxy, using the host codemonkey1.example.com (or localhost) and port 1080. Your web browser connects to your local machine’s port 1080, but the connection is forwarded over the SSH session to fedora1 in your home office, which connects to proxy to make HTTP requests. Anyone at example.com watching traffic will see only SSH traffic between codemonkey1 and fedora1.mydomain.com.

Observe Site Security Policies

Obviously, connections like this, as well as any network traffic, should be governed by Example.com’s IT security policies. Having secure, encrypted web browsing is nice, but having a job is good, too!

Service Administration

Let’s try another example. Say that you have a web-based administration tool that runs on your codemonkey1 host in Example.com, using port 8888, but you wisely block access to this port for any hosts other than itself (as localhost). Unfortunately, you’ve been working at an off-site example.com location for a few hours, when an urgent page comes in from your boss that requires immediate access to your web administration tool.

Fortunately, you can access SSH on that box, so no worries: local port forwarding to the rescue again! Issue the following command:


ssh -L 8888:localhost:8888 username@codemonkey1

Note that the hostname localhost in the command above indicates the way that codemonkey1 refers to itself. If you now open up a web browser and point it at port 8888 on the system you’re using at the off-site, you’ll see your web-based administration tool, just as if you were back at the console in your own office.

Confusingly, you might type this in the web browser’s location bar as http://localhost:8888, but in this case, the term localhost is simply a way of telling the web browser to connect to the system on which it’s running. To recap, your host’s HTTP request connects to itself at port 8888, which is forwarded over the SSH session to codemonkey1, which then connects to itself at port 8888.

Remote Port Forwarding

When you forward a port remotely, you make a port on the client system available on the remote system. Like local forwarding, this technique allows you to work around security measures that might otherwise prevent an IP connection. However, since the port becomes available on the server side, a new vista of possibilities opens for networking, like the following example.

A Remote Desktop Assistance Trick

You may already know about vino, the slightly tweaked VNC server that allows one user to remotely view or assist with another user’s desktop. The vino server normally listens on port 5900 for a connection to the default X server. If you run multiple X servers (concurrent graphical logins), add the X display number to 5900 to find out the port number used, or simply use netstat -ltp and list the ports. A helpful friend or administrator can run the VNC client (vncviewer) to connect to the other desktop. But what if the server in question, and the user needing help, can’t be reached through normal means?

Imagine a friend of yours needs remote help, but is behind a router not under his control that prevents you from using SSH to login to his system. Your system fedora1.mydomain.com, however, is not similarly disadvantaged.

First, set up an account for your friend on fedora1, using a username and password you agree on over a relatively secure channel. (Your friend is free to change the password at first login using the passwd command or the appropriate graphical utility.) Then relay this command to your friend over IRC, instant messaging, email, or some other method:

ssh -R 5900:localhost:5900 friend@fedora1.mydomain.com

In the command above, the first port number 5900 represents the port that will be opened on the remote host (fedora1.mydomain.com. The hostname localhost is the hostname your friend’s system calls itself. (Recall that if your friend has systems with ports he can reach, such as on a local or remote network, he can forward their ports remotely too!) The second port number 5900 is the port number on your friend’s system where his vino server is running.

Important: If your system has a process using port 5900, such as your own vino server, your friend will have to choose port 5901 for the first port number above.

You can now assist your friend by running the command vncviewer localhost. If your friend had to forward to port 5901 instead, use localhost:1 instead; for port 5902, use localhost:2; and so forth. Thus you can have several remote connections open at once to help a number of people at a time.

Conclusion

The flexibility of port forwarding goes far beyond the bounds of this article. Hopefully, though, these examples will spark your interest if you are starting to explore port forwarding.

13 responses to “SSH Port Forwarding”

  1. Georgi XpucToB says:

    I like the detail of this article; despite the fact the SSH port forwarding is well known (or at least well documented). I would like to see more technical articles like this one.

  2. Stefano Cavallari says:

    If you don’t need to really login on the machine, it’s better to use “-N” , so you won’t launch commands on the wrong machine by mistake.

    Another interesting trick is the ability of ssh to make a SOCKS proxy. (-D option)
    You don’t need an actual SOCKS proxy. Ssh and a (reachable!) server with internet access is all you need.
    For example, if you are on a restricted network and need to get out, or perhaps you just need to reach some web administration tools on the “remote” LAN the server is connected to, just do.
    ssh someserver -D 8080
    and you’ll get on localhost:8080 a socks proxy.
    if you want to share it with your friends in the LAN, you can by doing
    ssh someserver -D 192.168.1.0:8080
    assuming that 192.168.1.0 is the network address of your LAN.

  3. Paul W. Frields says:

    Georgi, thanks for your kind comments!

    Stefano, you’re absolutely right, and I use the SOCKS proxy option myself quite often. Using an existing proxy is sometimes helpful if part of the object is to cache your fetched materials where you’ll be able to reach them later. As I mentioned, this article really just scratches the surface of port forwarding, but certainly there are people doing ingenious things out there with the capability! Keep the hints coming.

  4. Ernie Oporto says:

    I’ve even used this in the past to forward my home iTunes Daap access to my work system:

    http://www.shokk.com/blog/articles/2006/02/06/getting-ipods-and-itunes-everywhere/

  5. Eric Zhang says:

    Thanks. This article helps me a lot!

  6. Grzegorz Witkowski says:

    Very interesting article. Thank you.

  7. Hrafn says:

    Thanks.

  8. sshforwarding says:

    Note that you can run one/both sides of a forwarding connection on a symbian mobile device. Very handy for running rsync to your mobile phone, getting at IMAP/SMTP email servers or using VNC over SSH.

    http://www.sshforwarding.com/

  9. Harish Rao says:

    Wow. An really interesting article. It has cleared lot of doubts. Thank you so much.

  10. prince2007 says:

    gr8 tut to clar up the idea

  11. Mugenyi Ismail Jr says:

    Have a problem forwading torrent to my windows server 2003 via
    a centos (installed with squid ) proxy need a solution plz help

  12. Need help with svn - openSUSE Forums says:

    […] Re: Need help with svn Yes, SSH can definitely do this. I saw a very good tutorial from Red Hat that walks through common setups. (Applies to openSUSE as well.) They also posed a follow-up article that is equally helpful. […]

  13. Lo hice y lo entendĂ­ | Creando tĂșneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH says:

    […] Red Hat Magazine: SSH Port Forwarding […]