Hack12.Secure VNC via SSH


Hack 12. Secure VNC via SSH

Easily encrypt your remote connections by setting up a secure tunnel.

VNC is a great way of getting access to a graphical desktop on a remote system. However, once you're connected, VNC uses standard TCP/IP for all traffic between the local viewer and the remote server. Anyone with a packet sniffer on your local network can grab packets and monitor your traffic, which is a bad thing if you're using the remote session for administrative tasks that will transmit passwords.

Luckily, it's quite easy to leverage the encryption provided by SSH, the Secure Shell, in your VNC sessions. You do this by setting up an SSH tunnel, which is essentially just a mapping between local and remote ports so that all traffic to a specified port on a remote machine is forwarded via SSH to a port on your local machine. This hack explains how to combine the power of VNC with the security of SSH to provide secure connections to remote machines. For general information about SSH, see the first volume of Linux Server Hacks by Rob Flickenger (O'Reilly), which devotes an entire chapter to SSH.

2.4.1. Forwarding Remote VNC Ports to Your Current Host

In addition to the standard secure shell functionality that most people use SSH for, SSH also enables you to forward traffic from a specific port on a remote machine to a specific port on your local machine. Doing this requires that a VNC server is already running on the remote machine, and that you establish a standard SSH connection to the remote machine but supply the L (local) option and an appropriate argument when you execute the ssh command.

The syntax for forwarding ports when using a standard SSH connection is the following:

 $ ssh -L  local-port:local-host:remote-port remote-host  

As discussed in "Access Systems Remotely with VNC" [Hack #10], standard VNC traffic with a given host takes place over port 590x, where x is the X Window System display that a specific VNC server is using. For example, to use SSH to forward VNC traffic from the VNC server running on the X Window System display:1 of the host nld.vonhagen.org to the same port on your local system, home.vonhagen.org, you would execute the following command:

 $ ssh -L 5901:home.vonhagen.org:5901 nld.vonhagen.org 

Once this tunnel is created, point your vncviewer at home.vonhagen.org:1 to establish a connection. When you supply the VNC password for the VNC server running on nld.vonhagen.org, a standard VNC window will display on your systembut the connection is secure. You can now type passwords, write love letters, or surf for a new job without anyone being able to sniff out what you're doing.

Even after forwarding a remote VNC port, the VNC server is still running on its original port on the remote host. Anyone who knows the VNC password to the remote system will still be able to connect to the VNC server normally, without the encryption you've set up through your locally forwarded tunnel.

If you are using the Java VNC viewer [Hack #11], you will also need to forward the port used by your VNC server's internal HTTP server. A VNC server's HTTP server uses port 580x, where x is the X Window System display that a specific VNC server is using. For example, in the previous command, the VNC server was using X Window System display:1, which meant that it was using port 5901 for standard VNC connections. Its web server is therefore using port 5801.


2.4.2. Public or Private VNC Forwarding

When forwarding ports in SSH, you can refer to your local machine using either its public hostname, which uses its standard IP address, or its loopback name, which maps the remote port to your host's loopback address. Each approach has its advantages.

Using the loopback address is best for security, because it requires that you be directly connected to your machine in order to access the remote VNC server through your loopback address. No one else can access the VNC server without being connected to your machine, since a loopback address (127.0.0.1) is specific to each host.

On the other hand, you may want to specify your host's public hostname if you want to be able to access the forwarded VNC from other hosts, or if you want to use a single system as an aggregator for connections to multiple VNC servers. The latter can be useful in enterprise environments where you want encrypted VNC connections but don't want to set up each one individually on whatever computer you're currently using. Using a specific system as a VNC aggregator provides the convenience of being able to access multiple VNC servers through a single host while still using the security provided by VNC's encryption, as shown in Figure 2-4.

2.4.3. Forwarding Ports Without Remote Login

Using the standard ssh command and the -L option requires that you actually establish an SSH connection to a remote machine, tying up whatever terminal session you're using to set up the port forwarding. To start up SSH port forwarding in the background, you can use the ssh command's -f (fork) and -N (no command) options, as in the following example:

 $ ssh -f -N -L  5901:localhost:5901 nld.vonhagen.org  

In this example, unless you've used SSH keys to set up passwordless SSH with the host nld.vonhagen.org, you'll still be prompted for your remote password. Once you enter it, SSH will set up the specified port forwarding and then return control to the local shell, rather than starting up a remote shell and connecting you to it. To terminate SSH port forwarding started in this fashion, you will have to locate and terminate the process using the Linux ps and kill commands or equivalents.

Figure 2-4. Multiple hosts using a single VNC aggregator


2.4.4. Improving Performance with Compression

Slow connections, such as those via modems and heavily loaded networks, can make using remote graphical applications painful. In these cases, you can optimize the bandwidth required for communicating with your remote VNC server by taking advantage of SSH compression. The ssh command provides a -C (compression) option that uses the same compression algorithms used by gzip to reduce the amount of data that you have to transfer back and forth over whatever wire you're using. To add compression to your SSH tunnel, just add the -C option to your existing ssh command line. For example, the command in the previous section would become the following to invoke compression:

 $ ssh -C -L  5901:home.vonhagen.org:5901 nld.vonhagen.org  

This command compresses all data exchanged between home.vonhagen.org and nld.vonhagen.org over the SSH tunnel.

Compression reduces the amount of data that needs to be exchanged over the tunnel, but it adds some processing overhead on both the client and the server in order to compress and decompress the data being exchanged over the tunnel. Compression may not be a good idea on slow or heavily loaded systems, but it's almost always a good idea over dialup connections. When using actual network connections, since both system and network load are transient, the only surefire way to gauge the possible benefits of compression is to experiment with using it.

2.4.5. Optimizing Graphical Updates Between Server and Viewer

As explained in detail in "Access Systems Remotely with VNC" [Hack #10], VNC supports a number of different ways to encode graphical update information when exchanging data between a VNC server and viewer. VNC viewers try to negotiate different encoding mechanisms depending on whether they believe that the VNC server is running locally or on a remote machine. Local connections always try to use raw encoding before trying any compressed encoding options. Raw encoding is extremely fast if the VNC server and viewer are running on the same machine, since local bandwidth is effectively infinite, but it's inefficient when communicating between a remote server and a local viewer.

When using SSH tunneling to redirect a remote VNC server to a local port, you'll want to override the default encoding settings to make communication between the VNC server and client more efficient, since the server is remote. If you're using the RealVNC vncviewer, specify the -PreferredEncoding hextile option on the vncviewer command line. If you're using TightVNC's vncviewer, you should specify -encodings "copyrect tight hextile" to take advantage of TightVNC's optimized encoding.

To find out which VNC viewer you're using (and therefore whether to try tight encoding), you can execute the command vncviewer --help. If you're using TightVNC, you'll see a string like TightVNC viewer version 1.2.9 as part of the output of this command. If you're using an RPM-based Linux system, you can also execute the command: rpm -qf `which vncviewer` to see which package provided the vncviewer command.


2.4.6. See Also

  • "Access Systems Remotely with VNC" [Hack #10]

  • Linux Server Hacks, by Rob Flickenger (O'Reilly)

  • http://www.tightvnc.com

  • http://www.realvnc.com



Linux Server Hacks (Vol. 2)
BSD Sockets Programming from a Multi-Language Perspective (Programming Series)
ISBN: N/A
EAN: 2147483647
Year: 2003
Pages: 162
Authors: M. Tim Jones

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net