On its own, the data exchange between a VNC Viewer and a VNC Server is in
"plaintext", so that anyone who can monitor (aka, "sniff") your network traffic
can see what you're seeing.

Fortunately, there are several standalone utilities which can be used to setup
encrypted tunnels between the VNC Viewer and Server. By telling VNC to use these
tunnels, instead of using a direct connection, your VNC data is now as secure as
any other data in the tunnel.

Using SSH or OpenSSH
Using PuTTY's SSH on Windows
Using Zebedee
Using Stunnel
Using Kaboodle
Using EchoVNC

Thanks to Barry Zubel, barry@zubel.co.uk, for this great answer to "what's all
this about sniffing, anyhow?".

------------------------------------------------------------------------------

For those of you interested in this 'ip sniffing, tunnelling and SSH'
stuff, here is a brief description. I'll try to give analogies
as-and-where I can.

For the normal, insecure, end-user (of which most of us in reality are),
the chances that your VNC connection will be 'sniffed' is pretty small.
Sniffing is basically a fond term given to the inspection of TCP-IP
packets as they cross over the internet.

We all know that the Internet is an interconnected network of networks.
Imagine, if you will, that it is actually the same as a country-wide
postal service.  Each TCP-IP packet is routed to-and-from the
destination by passing through various routers/networks.  Liken this to
your 'postcard' (TCP-IP Packet) being sent to a far destination has to
pass through your local mailbox (router), then the sorting office
(another router), then across the country by some means (another
router), and then through a remote sorting office (you should be
starting to get the idea), and then to the destination.

'Sniffing' your packet is the same as the postie at the other end
reading the back of your postcard before he delivers it. (In actual
fact, it could be a postal worker in ANY part of the chain).

To get around this problem, some geeky people (geeky being used fondly -
I regard myself as a geek!) out there developed something called SSH.
SSH is a method of 'end-to-end' encryption, which still passes over the
internet, but the information is scrambled so that it is illegible to
all but you and the destination. This would be the same as writing the
postcard in some secret code that only you or the destination
understand.

Now to the 'tunnel' part.  Once you have initiated an 'SSH connection',
it can be used to 'tunnel' lots of different types of information to the
host, in a secure way.  There are lots of different ways to achieve this
which I will not go into here, suffice to say that once this 'tunnel' is
operative, you can send any sort of data up-and-down it.

This is a difficult thing to think of an analogy for. Just believe me
that this 'tunnel' is pretty secure, and is not susceptible to 'sniffing'.

Fortunately, the original VNC developers created some great pages 
describing this task in detail. You can see it here:

http://www.uk.research.att.com/vnc/sshvnc.html

The essence of that How-To is this: to open an SSH tunnel from 
your machine to a VNC server, you need two things:

1. An SSH client on the VNC Viewer side of the connection
2. An SSH server on the VNC Server side of the connection.

Note that the the SSH client machine does not have to be the same 
as the VNC Viewer machine; likewise, the SSH server machine does 
not have to be the same as the VNC Server!

Start the tunnel from the SSH client side like this:

ssh -l username -L clientport:host:hostport SSH-server-address

After this tunnel connects, any data that goes into "clientport"
on the SSH client will go into the tunnel and then emerge from 
the SSH-server destined for port "hostport" on "host".

For example, suppose your SSH client is not the same as your VNC
Viewer, but the SSH Server is the same as the VNC Server. Also,
suppose your VNC Server was listening on "Display 2". The command 
to setup a tunnel for this case is:

ssh -l username -L 5902:127.0.0.1:5902 SSH-server-address

Now if you point a VNC Viewer to Display 2 on the SSH client, you 
will connect to the VNC Server. Note: since the SSH Server and
VNC Server on the same machine, you will need to enable the
"AllowLoopback" setting on your VNC Server.

Another great OpenSSH setup tutorial specific to WinNT can be found here:

http://www.ece.utexas.edu/~luo/winvnc_ssh.html

Thanks to Peter Coulter (peter at coulter.ndo.co.uk) for the info!

From John Aldrich:

I'd like to propose that you either host or link to  
http://www.benjamin.weiss.name/putty-tunnel.html

This is an EXCELLENT tutorial on how to configure PuTTY for SSH 
tunneling VNC. I just couldn't understand how to tunnel SSH until 
I saw this....

(thanks to John for the contribution!)

>>> This content is stolen^H^H^H borrowed directly from the Zebedee pages at 
http://www.winton.org.uk/zebedee/manual.html (just scroll down to the
"Use with VNC" down in "Examples"). <<<


One of the reasons behind writing Zebedee was to use it over dial-up lines 
with VNC. VNC is a free system to provide remote display capabilities using 
a “remote frame-buffer” concept. You can use it to display Windows desktops
remotely or, with an “Xvnc” server to access an “X desktop” from any VNC 
client machine, or even a Java-enabled browser! 

The supplied sample server configuration file server.zbd has sample target
statements (commented out by default) that are configured to allow redirection 
of ports 5900-5999 which will allow tunnelling of VNC sessions. This file can be
used on both UNIX and Windows but note that on Windows you must set the
“AllowLoopback” flag in the registry in order for tunnelling to work. Saving the
following snippet (without any leading spaces) in file and then importing it into
regedit will do the trick:

 REGEDIT4

 [HKEY_LOCAL_MACHINE\SOFTWARE\ORL\WinVNC3]
 "AllowLoopback"=dword:00000001

 [HKEY_LOCAL_MACHINE\SOFTWARE\ORL\WinVNC3\Default]
 "AllowLoopback"=dword:00000001

You will find a file with these contents in the Zebedee distribution by the name
vncloopback.reg. Having set these registry entries then the file vncviewer.zbd
can be used to invoke a VNC viewer tunnelled to the host named on the command
line. Here are the contents of the file vncviewer.zbd:

------start on next line---------------------------------------
 #
 # Zebedee configuration file to start up a tunnelled VNC session
 #
 # Usage: zebedee -f vncviewer.zbd remote-host:vnc-port
 #

 verbosity 1         # Basic messages only

 server false        # It’s a client
 detached true       # Detach from terminal

 message "Starting VNC viewer"

 # On Windows systems you might use the following:

 command ’"c:\Program Files\ORL\VNC\vncviewer.exe" localhost:%d’

 # On UNIX systems you might use the following:

 # command ’vncviewer localhost:%d’

 compression 6       # Request normal Zlib compression
--------end------------------------------------------------------

So using this file as follows:

 zebedee -f vncviewer.zbd somehost:5901

will start a VNC viewer tunnelled to the VNC server on somehost port 5901 
(the server you would usually refer to in VNC-parlance as “somehost:1”).

VNC also supports a Java viewer. If the server is running on port 59xx then 
the viewer can be downloaded via port 58xx. However, it appears that the Java
viewer communicates the main VNC port number to the client. So, to tunnel traffic
when using the Java viewer you must make sure that the local and remote
ports use the same numbers. So, for example, to tunnel traffic to a VNC server
using port 5901 you should do something like:

 zebedee 5801,5901:remotehost:5801,5901

This will be problematic if you already have a VNC server running locally on 
port 5901, but you can usually arrange local and remote VNC servers so that 
there is no clash.

There is one last point worth mentioning. If you are using compression with VNC
it is worth experimenting a bit with the VNC protocol encoding. I have found that
“raw” encoding often compresses best and sometimes gives better performance with
Zebedee over slow links. But, as they say, your mileage may vary!

Here's a great article which essentially covers everything about
setting up VNC to work well with Stunnel in a Windows environment:

http://www.securityfocus.com/infocus/1677

Stunnel is a program that allows you to encrypt arbitrary TCP connections 
inside SSL (Secure Sockets Layer), and is available on both Unix and Windows.
Stunnel enhances the security of non-SSL aware servers and protocols (like 
VNC), by providng good transport encryption for the data.

The following text is lifted from http://www.stunnel.org/examples/vnc.html

Definitions: 

Server    The machine on which you'll run a VNC server. You'll be viewing 
          this machine's desktop somewhere else. 

Client    The machine at which you wish to sit, launch a VNC client, and 
          view the remote (server) desktop. 


server$ stunnel -d 7777 -r 5901         # recieve from 7777, route decrypted
                                        # packets to local vncserver

server$ vncserver :1                    # start vncserver on first
                                        # screen (port 5901)

client$ stunnel -d 5901 -r server:7777  # tunnel vnc to server

client$ vncviewer localhost:1           # connect to local stunnel process

Thanks to MikeS for his details on using Stunnel between Windows machines:
--------------------------------------------------------------------------

Below is what I have setup using Stunnel 4.04 on Windows

The machine that is running the server only needs to map the port
used by the stunnel (in this example 7777) to the VNC port 5900.

The client machine maps local port to VNC servers thru the stunnel port
(again port 7777 in this example). I have is setup to use 127.0.0.1 or
127.0.0.1:5900 to go to one server, and 127.0.0.1:5901 to go to a totally
different server. 

All the files are just downloaded, and it seems to work fine. I don't know 
how to create the stunnel.pem files, so just have it using the one from the 
site.

[Server STUNNEL.CONF FILE - MAPS STUNNEL PORT to VNC PORT]

 client = no
 cert = stunnel.pem

 [vnc]
 accept = 7777
 connect = 5900

[Client STUNNEL.CONF File - Setup to be able to work with 2 VNC servers]

 client = yes
 cert = stunnel.pem

 [vnc]
 accept = 5900
 connect = xxx.xxx.xxx.xxx:7777
 [vnc2]
 accept = 5901
 connect = 192.168.0.8:7777

[Files in Directory from Stunnel.org]

LIBEAY32 DLL     1,379,459  12-31-02 11:54a libeay32.dll
LIBSSL32 DLL       476,329  12-31-02 11:54a libssl32.dll
OPENSSL  EXE     1,089,536  12-31-02 11:54a openssl.exe
STUNNEL  EXE        59,904  01-12-03  4:54p stunnel.exe
STUNNEL  PEM         1,690  02-28-03 12:24a stunnel.pem

Kaboodle is arguably the easiest VNC-securifier because it
automatically wraps your VNC connections into a secure tunnel
without asking you for any IP addresses or TCP port details.

With Kaboodle, you can also connect two LANs together, and
then connect to *all* of the VNC Servers on the far side, 
using the one connection. In this sense, it's sort of a "VNC
Proxy".

You can learn more here:  http://www.Kaboodle.org

Note: Kaboodle is a product of Echogent Systems, Inc., which hosts
      this FAQ-O-Matic website for VNC.

As described elsewhere in these FAQ's, EchoVNC allows
two VNC users to connect with each other regardless of
firewall or router configurations on either side.

In addition to making VNC "firewall friendly", EchoVNC can
be used to securely encrypt the VNC data connections. To
activate this feature, simply place the "libeay32.dll" file from
the OpenSSL package into the EchoVNC installation directory.
That will activate end-to-end 128-bit AES encryption of the 
VNC data.