Using VNC with SSH
Read this to know how to 'tunnel' the VNC protocol through SSH, to provide more security to your connection.
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). 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.
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:localhost: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:localhost:5901 snoopy
and any references to display :2 on your local machine would actually connect to display :1 on snoopy.
Note that the above SSH command-line is deliberately meant to accept incoming connections only from the local machine. This means that to use the SSH connection that we have just set up, we must connect to it from the same machine, using the special name 'localhost', rather than using the machine's own unique name.
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").