VNC logo

Virtual Network Computing

AT&T
[Home]
[screenshots]
[getting started]
[documentation]
FAQs
[download]
[keep in touch]
Others' ports and add-ons etc
Project ideas
VNC people
Search
[AT&T Laboratories Cambridge]

Making VNC more secure using SSH

VNC uses a random challenge-response system to provide the basic authentication that allows you to connect to a VNC server. This is reasonably secure; the password is not sent over the network. Once you are connected, however, traffic between the viewer and the server is unencrypted, and could be snooped by someone with access to the intervening network. We therefore recommend that if security is important to you, you 'tunnel' the VNC protocol through some more secure channel such as SSH.

If you are using Unix, this is pretty easy; SSH clients and servers are freely available for Unix.  Clients are also available for Windows, Macs, and other machines, but if you want servers on these platforms you may need to go for a commercial version, or to route your connection via a Unix machine (see later).  If you're using Java, check out the modified Java viewer created by Mindbright Technology. There are links at the bottom of this page to point you in the right direction for all of these things. The rest of this document refers to the Unix world, though the techniques will be relevant for other systems.  Frank Stajano has contributed a page which describes how he uses a free Windows SSH client to connect to a Unix server.

Installation

We won't go into details here about how to install SSH.  For my Linux machine I found two RPMs called ssh-clients and ssh-server.  I downloaded the source versions, built, and installed them, and this did almost everything, including the generation of a key for my machine.
You can get RPMs at http://rufus.w3.org/linux/RPM/ - for other distributions see the SSH FAQ.

Basic Use

SSH normally just provides you with a 'Secure SHell' - i.e. a login window to a remote machine. All traffic is encrypted between the two machines using public key encryption techniques, making it really very difficult for anyone else to spy on it.  Once SSH is installed, you could connect to a machine called 'snoopy' from elsewhere simply by running the SSH client:

    ssh snoopy

(You may need more options depending on your situation). You would then be prompted for the password of your account on snoopy and you would be logged in, just like a telnet session, but safer.  However, SSH has some nice extra tricks up its sleeve.  You can also request that it listens on a particular port on your local machine, and forwards that down the secure connection to a port on a machine at the other end.   For example,

    ssh -L x:snoopy:y snoopy

means "Start an SSH connection to snoopy, and also listen on port x on my machine, and forward any connections there to port y on snoopy."

Now, the VNC protocol normally uses port 59xx, where xx is the display number of the server.  So a VNC server on a Windows machine, which normally uses display number 0, will listen on port 5900.   Most Unix VNC servers will probably use display numbers 1,2, etc and so will be listening on ports 5901, 5902 and so forth.  If you forward these ports to a remote machine, you can make the remote VNC server appear to be a server running on your local machine.

So, imagine you had a VNC server running as display :1 on machine snoopy, and you wanted a secure connection to it from your local machine.  You could start the ssh session using:

    ssh -L 5902:snoopy:5901 snoopy

and any references to display :2 on your local machine would actually connect to display :1 on snoopy, so instead of running a vncviewer:

  vncviewer snoopy:1

you could run:

    vncviewer localhost:2

and you get the same effect, but with a secure connection.

A quick note if you're using the Unix VNC viewer to connect via SSH: By default, when the viewer connects to a server on the local machine, it uses VNC's 'raw' pixel encoding because this generally gives  better performance for local access. If this 'server' is actually an SSHD redirecting the data to another machine, you probably want to override this using the -hextile option to the viewer, or you will send a lot more data over the network than is necessary. (On the latest versions of the viewer, use -encodings "copyrect hextile").

Compression

SSH has another advantage.  It can compress the data as well.  This is particularly useful if the link between you and the server is a slow one, such as a modem, but even on a faster network it can help make up for the fact that the encryption takes a certain amount of time and so can slow the link down a little.  To add simple compression, use the -C option (or +C in ssh2). For more control, set it up in your ssh configuration files (see the man page for details). To see how much your data is being compressed, use the -v option. 

If you are on a slow link please read the note in the previous section about connections to local hosts.

More advanced use

In fact, the connection can be forwarded to a port on a third machine at the other end - it doesn't have to be snoopy that's running the VNC server, but remember that connections between snoopy and third machine will not be encrypted, only the one between you and snoopy.  And  you can tell ssh to allow incoming connections from other machines and forward those over the link as well. This can allow you to do really fun things like:
machine windows1 ------ machine
linux1
   
Runs vncviewer connecting to linux1:1, actually sees display of windows2  secure local network Runs ssh to linux2, fowards local port 5901 via link to windows2:5900  
|
|
insecure public network
|
|
    machine
linux2
---- machine
windows2
Runs sshd secure remote
network
Runs WinVNC server as display 0

To do this, you need to run the following on machine linux1;
   ssh -g -L 5901:windows2:5900 linux2

Lastly, remember  that if you want to use the Java VNC viewer, you will need to forward the 58xx ports as well as the 59xx ports.  See the FAQ for info on how these ports are used. 

Useful links

Acknowlegements

Many thanks to Axel Boldt, Miroslav Luptak & Luis B. Almeida for information which helped in the writing of this page. 
 

For comments, feedback, etc, please see the 'Keeping in touch' page.
Copyright 1999 - AT&T Laboratories Cambridge