Tunneling

Or how to encrypt non-encrypted connections....

The Theory

The basic idea is you set up a terminal session over SSH to a unix host, and then use port mapping to set up a virtual tunnel between your local host and the unix host. The unix host on the other end then acts as a proxy for your connections.

The Upside

  • Connections passed through the tunnel are encrypted, so services that rely on clear text passwords and non-encrypted connections can be made more secure, at least until the end of the tunnel
  • The connection to the remote services appears to come from the other end of the tunnel, so to remote hosts it looks like you're using the IP number of the remote login server. This means domain based authentication works, so you can reach news or send mail through the tunnel.

The Downside

  • You have to have a terminal connection in place to use the tunnel.
  • It's slower. Obviously, the data must be encrypted, and all of it goes through the one connection. And this technique introduces some additional overhead. Not much of a problem with mail or news services, but it does slow down ftp and web pages a lot.
  • Not everything works. For example, since you're setting one end of the tunnel as a port on your local host, you have to be able to tell the software on your end to use a local port as a destination. Not all software will let you do this--for example, FTP uses two ports, so confining the connection to a tunnel is tricky. SMB/CIFS (aka windows file sharing) is tough to set up, but you can do it if you stop the SMB service, see this guide.
  • For portable computers, you still have to support multiple configurations of clients or always use the tunnel (since you're mapping to a localhost port).

Ports

Of course, to set up a tunnel, you're going to have to know what port numbers are commonly assigned to standard services.

Setting Up a Tunnel

How you set up a tunnel depends on your ssh client. This example assumes that you are using a command line version of openssh, which is commonly available on unixy oses, and also available via http://www.itefix.no/ in the form of CopSSH for windows.

The example here is based on VNC, a program that allow a system to send it's keyboard, mouse and video to a remote host. VNC is popular with system administrators since it allows access to the GUI remotely. VNC can operate as an open server, and allow connections from any remote host, but that's not a very secure way to run it. A better way is to configure VNC to only allow connections from localhost, and then tunnel to the server with ssh. So let's say we've configured a server, mightymouse.unc.edu, with a VNC server, running on the default port of 5900, and that we've given the VNC service a good password and confined it to local host. From the command line on our workstation, we can connect to the server thusly:
ssh -L 5900:127.0.0.1:5900 myid@mightymouse.unc.edu
127.0.0.1 is a special ip address, localhost, and every machine interpretes that address to designate themselves. The -L flag says to map the port 5900 on my workstation to port 5900 on mightymouse. That means that if I try to connect a VNC client to 5900 on my workstation, it will actually connect to 5900 on mightmouse. Note that to do this, 5900 has to be free on my workstation. So the next step is to tell the VNC client software to connect to the server 127.0.0.1:5900.

Additional Examples