Using SSH tunnels to securely access a remote computer's services

May 2013

You have a SSH connection to a remote host. It's a terminal that you can use for many remote tasks. But now you want to transfer files, use the remote host as a browser proxy, run a remote desktop, etc. These services, provided they are installed/configured on the host, can be accessed securely using SSH tunnels. See Easy, secure remote connections to learn one way to setup SSH and initiate these tunnels.

Browser tunnels

Use a dynamic (eg D8084) tunnel:

Firefox: Firefox → Preferences → Advanced → connection → settings: Manual Socks Host 127.0.0.1:8084

IE: Tools menu → Internet Options item → Connection tab → LAN Settings button → Under Proxy Server click Advanced → Socks 127.0.0.1 port 8084

Most other browsers can be configured similarly.

Remote Desktops via SSH with Linux Clients

Sometimes VNC connections to servers running the newer Linux distributions like Cinnamon and Unity are buggy. If you are getting black screens, unusably sluggish rendering, missing menus and icons, etc, when you connect, then run the host in gnome fall back mode (apt-get install gnome-session-fallback).

Remmina will connect to Linux VNC hosts and Windows Remote Desktop. If you want to reach a Linux VNC from Windows, shop for a third-party VNC client that can use a tunneled port and does connect from Windows to Linux. I have no informed suggestions on the best program for this.

Linux Clients to Linux Hosts

Use Port 5900 tunneled to localhost:5092

X11vnc is my preferred VNC server for Linux hosts. It seems to be the most compatible server with multiple distributions on different machines. With x11vnc, you can start the server just once from an established Putty session. It will terminate when you close the VNC session. You can install it with 'sudo apt-get install x11vnc'.

Start it from the logged in Putty session with x11vnc -display :0. There are many other x11vnc options (run man x11vnc). Sometimes an earlier session will leave your target port (5900) in a listening state. Making a new server session will increment the listening port to 5901, an undesirable effect when your tunnel forwards to 5900. From a second Putty session to the same machine you can kill the process and restore the default port on the next try. Run ps aux | grep x11vnc, read the offending session process id number from the output, and run kill -9 PID#.

You will get a nasty warning when you run x11vnc from the Putty terminal: "You Are Running x11vnc Without a Password." You don't care provided the host only exposes the SSH service (firewall!). The only available port should be the SSH port, through which you have an encrypted VNC session.

Linux Clients to Windows Hosts via Windows Remote Desktop

Use Port 3390 tunneled to localhost:3389. Setup Windows Remote Desktop on the host but be sure to exclude direct connections to port 3389 in the firewall.

Reminna VNC Client

Once you have the host VNC server installed, configured, and running, you need a VNC client installed on your client in order to render the remote desktop. I prefer Remmina. Install it. After connecting to the host and starting x11vnc, your client can access the VNC desktop using Remmina.

Linux client to Linux Host

Linux client to Windows Host

Remote Desktop with Windows Clients and Windows Hosts

Setup Windows to accept remote desktop connections on the host. Configure a Putty ssh tunnel from source port 3390 to Localhost:3389 on the remote machine and connect with Putty as usual. From the client Windows machine, go to Start → Accessories → Remote Desktop Connection, and enter 127.0.0.1:3390.

File transfer

This example uses Filezilla... my FTP client of choise. Yes, files can be transfered using command line tools typed directly into the SSH terminal. But, I like gtk front-ends when they are well designed, versitle, and cross-platform and Filezilla is just that. I like drag and drop.

An FTP client runs on your client computer. In order to be able to use it, you need an FTP server on the host. Exposing an FTP server to the Internet and using it directly should be avoided. Instead, firewall the FTP server and SSH tunnel into it. For an added comfort level, don't run it as a daemon. Rather, start the service from the SSH terminal the moment you need it... and stop it when you are done.

I use vsftpd as my FTP server on Linux hosts. There are FTP servers for Windows but I have no experience with them (in general, I never run an unattended, native Windows system). Disable the daemon by editing /etc/init/vsftpd.conf and commenting the line that reads start on runlevel [2345] or net-device-up IFACE!=lo.

Customize vsftpd by editing /etc/vsftpd.conf (note: different location from daemon initializer). Start with following uncommented lines then, when you have a working server, further restrict the server as you see fit:

Configure SHH with a dynamic tunnel to a Port (eg 4000).

Run sudo start vsftpd from your SSH terminal to enable it. Stop it when you are done: sudo stop vsftpd.

On the client, configure Filezilla to use a Generic Proxy from the Edit → Settings menu

From the File → Site Manager menu, create your site:

There are many other services that you can tunnel: web servers, email servers, etc. Additionally, if you are into programming, you can roll your own. For example, you can create a webcam viewer that streams an image over a port.

Is using SSH tunnels perfectly secure? No, nothing is, but it's pretty darn secure. On any computer, exposed to the world or not, don't store anything that you cannot tolerate sharing. If you must, look into encryption, and don't rely on trivial passwords..

By the way, you can monitor what traffic you send over the network with a packet sniffer. Look into Wireshark for a good start. If you have a second computer (or a virtual machine) you can insert it between your computer and the router and view the traffic exactly as your ISP or any other man-in-the-middle could. Monitoring your network (and I stress the word your) is a great way too learn. When you do this, you will become a big advocate of SSH tunneling. Never monitor a network unless it is entirely yours and everyone using it is aware that you are doing this.