VNC over SSH2 - A TightVNC Tutorial


Van Emery - June, 2003



Introduction:

If you have ever needed to access a GUI desktop on a remote machine, you will appreciate TightVNC.  It is cross-platform, Open Source, works well, and is free.  When coupled with SSH, it is also very secure.  It solves some of the same problems as X over SSH, but uses less bandwidth to do it.  System administrators and power users alike will appreciate TightVNC, as it will add another flexible tool to their repertoire.  

This tutorial is not about using VNC through a web browser, or via the traditional unencrypted methods.  This tutorial focuses on the following:

-  Linux/Unix to Linux/Unix secure connections, especially over low-bandwidth WAN links
-  Win32 to Linux secure connections

We will also take a look at bandwidth utilization and quality compared to X over SSH, and security considerations.  When complete, you should be able to use TightVNC over SSH2 to assist you in your daily work.

TightVNC and VNC both have excellent documentation on their respective webpages, and I urge you to take a look for yourself if you want more information on how to use VNC for other tasks.  Also, the man pages that come with the TightVNC packages are well-written and thorough.



The Basics:

What is VNC?

VNC stands for Virtual Network Computing, and it was developed at the Olivetti & Oracle Research Laboratory (Cambridge, England) in 1994.  Originally running on an ATM-connected thin client device, it was ported to other platforms, including Win32, Unix, GNU/Linux, and Mac OS.  It is a remote display system which allows a thin client to remotely access a desktop GUI environment on another computer over the network.  

Since it is platform independent, you can remotely run an Apple desktop from a Windows client, or a Unix desktop from an Apple client, and so on.  The thin client (called the VNC viewer) is small enough to fit on a floppy or run from a Java-enabled web browser.  Other cool features include the ability to share a desktop session with more than one client, and the "stateless" nature of the VNC viewer.

What does this mean to a Linux/Unix administrator or power user?  It means that you can run a GUI desktop on a remote machine, over a LAN or over the Internet.  For a complete overview and complete documentation, see the Virtual Network Computing homepage .


The VNC Protocol



From the VNC homepage, a description of the VNC protocol:

The VNC protocol is a simple protocol for remote access to graphical user interfaces.   It is based on the concept of a remote framebuffer RFB. In the past we have tended to refer to the VNC protocol as the RFB protocol, so you may have seen this term in other publications.  The protocol simply allows a server to update the framebuffer displayed on a viewer. Because it works at the framebuffer level it is potentially applicable to all operating systems, windowing systems and applications. This includes X/Unix, Windows 3.1/95/NT and Macintosh, but might also include PDAs, and indeed any device with some form of communications link. The protocol will operate over any reliable transport such as TCP/IP.

VNC Overview Picture


This is truly a "thin-client" protocol: it has been designed to make very few requirements of the viewer. In this way, clients can run on the widest range of hardware, and the task of implementing a client is made as simple as possible. 





What is TightVNC?

TightVNC is an enhanced version of VNC.  It includes better compression algorithms for improved performance over WAN links, as well as new features like automatic SSH tunneling between Unix/Linux hosts.  For a complete list of enhancements and complete documentation, see Constantin Kaplinsky's TightVNC homepage.


What is SSH?

SSH, or the Secure Shell, is the "Swiss Army knife" of host-to-host networking.  It allows secure (encrypted and authenticated) connections between any two devices running SSH.  These connections may include terminal (CLI) sessions, file transfers, TCP port forwarding, or X Window System forwarding.   SSH supports a wide variety of encryption algorithms, including AES-256 and 3DES.  It supports various MAC algorithms, and it can use public-key cryptography for authentication or the traditional username/password.  The good news is that SSH does not cost anything on the client or server side, although there are some nice SSH packages for MS Windows that require you to purchase commercial licenses.

For more info on SSH, check out the official OpenSSH website .

Getting the Software:

You can get the latest binary packages or source Tarballs at TightVNC.com.  For this tutorial, I used the Red Hat 7.x packages, which also worked perfectly on Red Hat 8.0.  For your convenience, I have placed the RPMs here on this page, as well as the viewer for Win32 clients:




Package Description
 Click Link to Download
TightVNC Server RPM Package (x86)
 tightvnc-server-1.2.8-1.i386.rpm            
TightVNC Viewer RPM Package (x86)
 tightvnc-1.2.8-1.i386.rpm
TightVNC Viewer for Windows
(No installation necessary, just unzip and run.)
 tightvnc-1.2.8_x86_viewer.zip


Installing the Software:


Your Red Hat install may have included the standard VNC packages.   To uninstall the existing VNC packages:

rpm -qa | grep vnc

If VNC packages are installed, you will remove them with the following command:

rpm -e pkgname

From the directory with the new TightVNC packages, install them with:

rpm -ivh tight*rpm





How to use TightVNC over SSH - Examples:


Here you will see:

1.  TightVNC over SSH from one Linux host to another over the LAN
2.  TightVNC over SSH from one Linux host to another over a trans-Pacific WAN
3.  TightVNC over SSH from a Win32 PC to a Linux host.

Environment:

Red Hat 8.0 on a Pentium III IBM Thinkpad Laptop (LAPTOP)   192.168.1.191
Red Hat 7.3 on a Pentium II 400 MHz Dell Optiplex (LAB)
Red Hat 7.2 on a Pentium II 350 MHz Dell Optiplex (HOUSE)
Red Hat 8.0 on a Pentium III 667 MHz generic tower, 256 MB RAM (RAT)   192.168.1.2

Assumptions:

1.  You have X server software on your "local" system, the system that will run the TightVNC viewer (client).
2.  The remote system (should be a Linux or Unix host) should have X window support, and Gnome, KDE, or some other desktop environment.  It also needs to have the TightVNC server package installed.
4.  The firewalling setup on your hosts allows the SSH session to take place.
5.  You have sshd configured and running on the remote system.


Example #1 - TightVNC over SSH from LAPTOP to RAT with the same username, using the default SSH port, TCP 22

On RAT, enter the following:

[vncuser@rat .vnc]$ vncserver :64 -geometry 1024x768 -depth 16 -name RAT

You will require a password to access your desktops.

Password: ********
Verify: ********
Would you like to enter a view-only password (y/n)? y
Password: ********
Verify: ********

New 'RAT' desktop is rat:64

Starting applications specified in /home/vncuser/.vnc/xstartup
Log file is /home/vncuser/.vnc/rat:64.log

[vncuser@rat .vnc]$

[vncuser@rat .vnc]$ netstat -ta
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 *:32768                 *:*                     LISTEN
tcp        0      0 *:5864                  *:*                     LISTEN
tcp        0      0 *:ssh                   *:*                     LISTEN
tcp        0      0 *:5964                  *:*                     LISTEN
tcp        0      0 *:sunrpc                *:*                     LISTEN
tcp        0      0 *:6064                  *:*                     LISTEN
tcp        0      0 *:x11                   *:*                     LISTEN
tcp        0      0 *:http                  *:*                     LISTEN
tcp        0      0 *:ftp                   *:*                     LISTEN
tcp        0      0 rat:smtp               *:*                      LISTEN
tcp        0      0 *:https                 *:*                     LISTEN

Now the server is listening on ports 5864, 5964, and 6064. (5800 + display#=5864), (5900 + display#), (6000 + display#)


On LAPTOP, type the following:

(You must be in an X session!  Note that the display number is very important.)

[vncuser@Laptop vncuser]$ vncviewer -via 192.168.1.2 mysql:64
[email protected]'s password:
VNC server supports protocol version 3.3 (viewer 3.3)
Password:
VNC authentication succeeded
Desktop name "vncuser's RAT desktop (rat:64)"
Connected to VNC server, using protocol version 3.3
VNC server default format:
  16 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 31 green 63 blue 31, shift red 11 green 5 blue 0
Using default colormap which is TrueColor.  Pixel format:
  16 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 31 green 63 blue 31, shift red 11 green 5 blue 0
Using shared memory PutImage
Tunneling active: preferring tight encoding

===============
From ~/.vnc/rat:64.log

29/05/03 22:01:39 Got connection from client 127.0.0.1
29/05/03 22:01:39 Protocol version 3.3
29/05/03 22:01:43 Full-control authentication passed by 127.0.0.1
29/05/03 22:01:43 Pixel format for client 127.0.0.1:
29/05/03 22:01:43   16 bpp, depth 16, little endian
29/05/03 22:01:43   true colour: max r 31 g 63 b 31, shift r 11 g 5 b 0
29/05/03 22:01:43   no translation needed
29/05/03 22:01:43 Using tight encoding for client 127.0.0.1
29/05/03 22:01:43 Using image quality level 6 for client 127.0.0.1
29/05/03 22:01:43 Enabling X-style cursor updates for client 127.0.0.1
29/05/03 22:01:43 Enabling cursor position updates for client 127.0.0.1
29/05/03 22:01:43 Enabling LastRect protocol extension for client 127.0.0.1


Screenshot of TightVNC over SSH session from LAPTOP to RAT over LAN
Note the TightVNC control window.  The <F8> key displays the window, from here you can end your VNC session.

To close the session, use the <F8> key and select the "Quit Viewer" option.  This will disconnect you from the VNC server, but it will leave the desktop and all of the programs running.  When you connect again from LAPTOP or any other host, you will begin again exactly where you left off.  This is why the VNC viewer is considered "stateless".

TIP:  Do not close the remote destop or window manager in the typical way.  If you do this, you will have to restart the VNC server on RAT before you can connect and use the GUI again.

If you do not want to keep the VNC server running when you are done, login to RAT and issue the following command:

[vncuser@rat vncuser]$ vncserver -kill :64
Killing Xvnc process ID 28357
[vncuser@rat vncuser]$

Now you will  not be able to connect from a remote host again until you restart the VNC server.

More Info

Changing the VNC password:  

Login to the host with the Xvnc server.  Use the "vncpasswd" command.  Passwords must be 6 characters or longer.  If you want to have a view-only password as well, you will be prompted for one.

Checking out the log:

The host with the Xvnc server will have a directory called .vnc in your home directory.  That directory has a file called hostname:display#.log,  which contains useful debugging information.  If you need to watch the log during VNC connections, you can use the "tail -f ~/.vnc/rat:64.log" command.

If you are on a high-speed LAN:

You do not need to use the "tight" encoding, which includes lots of compression, when using TightVNC over SSH on a switched LAN.  I recommend the "Hextile" encoding, which would be invoked from the remote host like this:

vncviewer -encodings Hextile -via 192.168.1.2 mysql:64


Example #2 - TightVNC over SSH from LAPTOP to LAB and HOME on Trans-Pacific WAN

-  Different user names (vncuser on local "client" end, vanimal on remote "server" end)
-  Non-standard SSH port (TCP 8400 instead of TCP 22)
-  Long-distance WAN link (21 router hops, including a NAT firewall on both ends.  Average round-trip PING latency = 555 ms)
-  Slowest link = 768 Kbps down / 128 Kbps up ADSL link in Asia

In this scenario, we want to enable compression and maximize our performance over the WAN.  Our settings will be as follows:

-  Small desktop on remote "server" end:  800 x 600
-  8-bit color depth
-  Display :20
-  Simple, solid background on "server" end
-  Tight encoding with extra JPEG compression (q=1 instead of the default q=6)


On LAB (the remote end), login via SSH as vanimal and start the server:

[vanimal@punk vanimal]$ vncserver :20 -depth 8 -geometry 800x600 -name LAB

You will require a password to access your desktops.

Password: ********
Verify: ********
Would you like to enter a view-only password (y/n)? y
Password: ********
Verify: ********
xauth:  creating new authority file /home/vanimal/.Xauthority

New 'LAB' desktop is punk:20

Creating default startup script /home/vanimal/.vnc/xstartup
Starting applications specified in /home/vanimal/.vnc/xstartup
Log file is /home/vanimal/.vnc/punk:20.log


On LAPTOP (the local end), you will need to set the VNC_VIA_CMD environment variable in order to use an alternate SSH port and a different username:

[vncuser@Laptop ]$ export VNC_VIA_CMD='/usr/bin/ssh -2 -c aes128-cbc -x -p 8400 -l vanimal -f -L %L:%H:%R %G sleep 20'

Notes:
-2 forces SSH version 2
-c aes128-cbc specifies a fast, strong cipher (better than 3DES)
-x makes sure that X over SSH forwarding is disabled for this SSH connection
-p specifies the non-standard TCP port number for the SSH server
-l specifies a different username on the remote end than the client on the local end
-f -L %L:%H:%R %G sleep 20 are defaults from the vncviewer manpage


[vncuser@Laptop ]$ vncviewer -encodings Tight -depth 8 -quality 1 -via punk mysql:20


Notes:     

-Tight encoding includes several types of compression.
-via invokes SSH using the $VNC_VIA_CMD environment variable
-depth 8 calls for 8-bit color, it improves the look of GUI detail at high JPEG compression rates
-quality 1 (very high JPEG compression of some portions of the screen.  Only 0 is higher)



Screenshot of TightVNC over SSH session from LAPTOP to LAB over WAN



Working with the $VNC_VIA_CMD environment variable:

If you do not want to type in the export command every time you want to run vncviewer, you should add the environment variable assignment to the .bash_profile script in your home directory.  I added the following lines to the end of my .bash_profile file:
# For Tight VNC to LAB

VNC_VIA_CMD='/usr/bin/ssh -2 -c aes128-cbc -x -p 8400 -l vanimal -f -L %L:%H:%R %G sleep 20'
export VNC_VIA_CMD

When you log back in, the environment variable will be set.  You can check this with:

echo $VNC_VIA_CMD   or   env | grep VNC

       

Other items:  

-  Once logged in to the remote LAB desktop, I changed the screensaver to a blank screensaver, and made sure the background was a solid color, instead of a complex pattern or picture.  

-  If you would like to change the default X Window Manager or Desktop Environment used on the remote machine, edit the ~/.vnc/xstartup file.  You will want to comment out the default entry and add your own at the bottom.  Here is mine:

#!/bin/sh

# Red Hat Linux VNC session startup script
#exec /etc/X11/xinit/xinitrc

exec mwm

Now you will need to kill the Xvnc server and restart it:

[vanimal@punk .vnc]$ vncserver -kill :20
Killing Xvnc process ID 575
[vanimal@punk .vnc]$ vncserver :20 -geometry 800x600 -depth 8 -name LAB

New 'LAB' desktop is punk:20

Starting applications specified in /home/vanimal/.vnc/xstartup
Log file is /home/vanimal/.vnc/punk:20.log

This will give you a more responsive GUI over a slow WAN connection.  You can use your favorite no-frills X window manager, such as twm, BlackBox, or WindowMaker instead of mwm.  This will cut down on bandwidth utilization compared to Gnome or KDE.
I was also able to test a high-compression session from RAT to HOME.  This trans-Pacific communications path included 12 routing hops, 2 NAT firewalls, and ADSL on both ends.  The average round-trip latency for this path (from PING) was 191ms.  Response was fairly good.

The screenshot below shows a TightVNC session from RAT (which was using the WindowMaker window manager) to LAB (which was running Gnome).  This was via the 21-router hop trans-Pacific route.

Session from RAT (running WindowMaker) to LAB (running Gnome) over WAN

Example #3 - TightVNC over SSH from a Win32 PC

Is it possible to use the TightVNC viewer over SSH from a Win32 PC?  Yes, it is.  It is not as straightforward as running it from a Unix or Linux host, but it is not difficult.  For this example I used the following:

-  Laptop running Windows XP
-  SSH client (SecureCRT and PuTTY both worked)
-  TightVNC Viewer for Win32


Here is a screenshot of a TightVNC session from Windows XP to a VNC server on RAT.  In this case, PuTTY was used as the SSH port-forwarding mechanism:

Session from Windows XP to a VNC server on RAT.

How can we configure this?  

-  First of all, you need to setup your SSH client so that it can login to the host that will be running the TightVNC server.
-  Second, the TightVNC server needs to be running and you need to know the display number.  In my case, the display number was :64.
-  Third, you must setup TCP port forwarding or "tunneling" on your SSH client.  We have to select an unused TCP port on the Microsoft Windows machine, then select the foreign address as 127.0.0.1 (because the VNC session will occur on the same host as the SSH server), and select the foreign port appropriate for display :64.  Below, you can see the port forwarding setup for a PuTTY SSH client.  You should be able to configure port forwarding on other SSH clients, like SecureCRT.

VNC-PuTTY Port Forwarding Setup Screenshot of PuTTY port forwarding setup for TightVNC over SSH

In the configuration screenshot above, you will note that two different ports are being forwarded.  That is because you can have multiple instances of TightVNC running on the server host, and you can use multiple TightVNC clients on your remote/client machine!  

Now that everything is configured, you must start your SSH client, connect to the server, and login.  The SSH terminal must stay open while you are tunneling TightVNC through SSH.  When you run the TightVNC viewer (client), you will actually put in the following addresses:

127.0.0.1:64    - or -    127.0.0.1::5964

This may not seem intuitive, but you are connecting the VNC viewer to the SSH tunnel, not the IP address of the remote host.  The first notation is the standard VNC display number, the second actually specifies the port.  You don't have to use TCP port 5964 on the VNC viewer side, you could also use TCP port 3333 as long as the port forwarding configuration on the SSH client is entered properly.

The TightVNC viewer for Windows also has an "Options" button that opens a configuration panel that lets you adjust parameters such as encoding type, compression, color depth, etc.

To terminate the VNC session, you will not use the <F8> key, you will right-click the title bar and close it from there.  Then you can end your SSH terminal session.

Unlike the Linux version, you have to open the SSH terminal session first, and close it afterwards.


Performance Characteristics:

Compared to running X over SSH, TightVNC uses more CPU resources on the server side; however, it uses less bandwidth in the remote Desktop Environment tests that were conducted.  Full GUI desktop responsiveness was better over trans-Pacific WAN links than "X over SSH" sessions over the same links.  Performance over the WAN was generally good, with average bi-directional bandwidth utilization well below 80 Kbps.


TightVNC over SSH Traffic Chart


Scenario            
 		Avg. BW Util.
(bi-directional)
 		Packets Per Sec.
(bi-directional)
 		Avg. Packet Size
 		Comments
                                  
LAN with Hextile encoding, Depth 16  1024x768  (1)
 		1485 Kbps
 		229 pps
 		811 bytes
 		Fast and responsive
LAN with Tight encoding, Depth 16, Quality 6  1024x768  (1)
 		474 Kbps
 		118 pps
 		504 bytes
 		Fast and responsive
LAN with Tight encoding, Depth 8, Quality 1  (2)
 		246 Kbps
 		88 pps
 		349 bytes
 		Fast and responsive
LAN with Tight encoding above, Gedit session  (3)
 		61 Kbps
 		43 pps
 		178 bytes
 		Fast and responsive
WAN with Tight encoding, Depth 8, Quality 1 (LAB)  (4)
 		42 Kbps
 		11 pps
 		490 bytes
 		Usable, but noticeable delay
WAN with Tight encoding, Depth 8, Quality 1 (HOUSE)  (4)
 		66 Kbps
 		15 pps
 		553 bytes
 		Usable, but noticeable delay
WAN with Tight encoding above, Gedit session (HOUSE)  (5)
 		18 Kbps
 		11 pps
 		210 bytes
 		Usable, but irksome delays


Notes:

The TightVNC server desktop used was Gnome in all cases.  SSH2 with AES128-CBC was the transport mechanism for the VNC traffic.  Unless otherwise noted, desktop size was 800x600 pixels.  The test consisted of the following:  Opening iagno, moving the window left and right, then letting the server play the game against itself.  Then, a terminal window was opened and the top utility was executed.  Top was then stopped and xdaliclock -24 -cycle was started.  The xdaliclock window was then moved all around the screen and closed.  After that, kasteroids was selected from the game menu and played.  The game was then closed.  Traffic stats were gathered by Ethereal.

(1)  Session was so responsive, it was hard to tell that it was occurring over a network.  Kasteroids was completely playable.  The only negative comment I have is that moving windows around the desktop spiked RAT's CPU utilization as high as 100%!  Scrolling windows, resizing windows, and moving windows seems to be very CPU intensive on the Xvnc server side of things.
(2)  Session very responsive.  8-bit color looks fine for any administrative duties.  Same CPU utilization issue as in note (1).
(3)  Gedit was perfectly usable, no noticeable delays.
(4)  Although the delay/lag was noticeable, the desktop and apps were usable.  Kasteroids was not playable, though.
(5)  Gedit was doable, but the delay between pressing a key or moving the cursor and seeing the result was annoying.  A straight SSH session in text mode is more responsive and uses less bandwidth.

Security Considerations:

As an administrator, you will want to understand, and perhaps tighten down, the security of TightVNC.  First, you must understand which ports are opened up when you are running the Xvnc server:
1.  TCP port 5900 + display #    (This port listens for incoming connections from VNC viewers (clients))
2.  TCP port 5800 + display #    (This port is associated with a small web server that dishes out a TightVNC Java client)
3.  TCP port 6000 + display #    (This port is associated with the standard X server listener)
4.  TCP port 22    (Default port for SSH server)

Do you really need all of these ports open in order to run TightVNC over SSH to the host?  Let's take a look:

TCP port 5900 + display #

This port is wide open.  It is used when SSH is not employed.  Target location should be simple with a port scanner.  Although the password is not passed in the clear, it is vulnerable to DoS attacks, buffer overflows, and password guessing.  Also, once a traditional VNC session is running over this port, the session is unencrypted.  Best defense:  Don't allow anything but the loopback (127.0.0.1) to listen on this port.  Use the -mysql option when running the vncserver command.

vncserver :64 -depth 8 -geometry 800x600 -mysql -name RAT

Now check on RAT with the netstat -tn | grep LISTEN command.  It should now be listening on 127.0.0.1 only.  When you try to connect from a remote host without the -via option, it should now fail.  You can use Nmap to confirm that no VNC ports are listening on RAT's Ethernet address.
Note:  Even though it only listens on the loopback, a local GUI user on your server can still connect without SSH to 127.0.0.1 and bring up a session.  That is one reason why you may want to restrict the vncviewer software as detailed later in this section.  Also, another user on the system can tunnel a VNC session over SSH from a remote host and connect to your session.  In this scenario, only your VNC password prevents entry.

TCP port 5800 + display #

This is where the small built-in HTTP server listens.  It will serve a Java viewer to web browser clients.  This will hand the Java app to anyone who wants it.  It may be susceptible to buffer overflows or other attacks.  For VNC over SSH, this does not need to be running on any external interfaces.  This is also turned off by using the -mysql option with vncserver command.  Both the 5800+ ports and the 5900+ ports will only listen on the loopback after this option has been used.

TCP port 6000 + display #

Standard X server listening port.  This will be available to external hosts, although remote X sessions will be rejected.  They are rejected even if the user on RAT uses the "xhost +" command.  This seems to be O.K.,  but I would prefer to hide the X server ports with iptables or ipchains rules.

TCP port 22

Since you have to use SSH in order to run TightVNC over SSH, you must be able to get to the SSH port.  You may want to edit the /etc/ssh/sshd_config file to use a non-standard port.  You will also want to make sure that you patch or update your OpenSSH server any time a security-related patch or upgrade is released.

Passwords:

These are changed with the vncpasswd command.  One password is for view-only, and one is for full control.  The only password checking that is done is checking for a minimum of 6 characters.  There is no password aging or central policy enforcement.  This is O.K.,  because you have to enter your SSH password in order to get into the account before you can enter the TightVNC password.  The key to the account is the SSH password.  That being said, I would still not use the same password for the VNC account that I used for SSH.  The file is located here:  ~/.vnc/passwd (mode 0700), and it is not in plain text.

Who can use TightVNC on your  host?

By default, once you have installed the TightVNC server packages, any user on your system could run an Xvnc server.  They may set it up without the -mysql option, use VNC without SSH, use trivial passwords, leave a screensaver running, etc.  Another issue is that any user with the ability to run the vncserver or Xvnc command can run multiple instances of the VNC server, and hog up system resources.  If a screensaver is running on all of those instances, your server performance could take a real hit!  Do you want to allow this?  I wouldn't.  I would recommend that you create a group for users who are allowed to execute the TightVNC server commands.  Add selected users to the new group that will be allowed to run TightVNC servers.  This should help eliminate potential problems.    Also, the vncconnect program is used as a "VNC relay".  This can be disabled with chmod or by removing it altogether if you have no use for it.

Also, I would recommend NOT running a TightVNC server as root, and I would even recommend against running it from your normal user account.  Create a special user account strictly for running GUI apps/desktops over TightVNC over SSH.  You can still su - to root from a terminal window if you need to.  This will help cut down on desktop setting conflicts between a running desktop session on the host and a remotely-initiated desktop session over VNC.  It will also encourage you to use an appropriate non-bandwidth-hogging desktop environment and apps.  When you jump on the machine locally, you won't have to reconfigure everything.
Here is how I added a new VNC server group, and added two users to that group, then changed some permissions:

[root@rat bin]# groupadd tvnc
[root@rat bin]# usermod -G tvnc vncuser
[root@rat bin]# usermod -G tvnc gomer
[root@rat bin]# grep tvnc /etc/group
tvnc:x:506:vncuser,gomer

[root@rat bin]# id vncuser
uid=505(vncuser) gid=505(vncuser) groups=505(vncuser),506(tvnc)

[root@rat bin]# id gomer
uid=500(gomer) gid=500(gomer) groups=500(gomer),506(tvnc)

[root@rat bin]# cd /usr/bin
[root@rat bin]# ls -al *vnc*
-r-xr-xr-x    1 root     root         3992 Jan 30 04:28 vncconnect
-r-xr-xr-x    1 root     root        12312 Jan 30 04:28 vncpasswd
-r-xr-xr-x    1 root     root        15137 Jan 30 04:17 vncserver
-r-xr-xr-x    1 root     root        86604 Jan 30 04:28 vncviewer
-r-xr-xr-x    1 root     root      1248620 Jan 30 04:28 Xvnc

[root@rat bin]# chmod 0550 *vnc*
[root@rat bin]# chgrp tvnc *vnc*
[root@rat bin]# chmod 0000 vncconnect
[root@rat bin]# ls -al *vnc*
----------    1 root     tvnc         3992 Jan 30 04:28 vncconnect
-r-xr-x---    1 root     tvnc        12312 Jan 30 04:28 vncpasswd
-r-xr-x---    1 root     tvnc        15137 Jan 30 04:17 vncserver
-r-xr-x---    1 root     tvnc        86604 Jan 30 04:28 vncviewer
-r-xr-x---    1 root     tvnc      1248620 Jan 30 04:28 Xvnc


Sharing:

By default, TightVNC sessions can be shared, including mouse and keyboard control.  There is plenty of information on this feature on the TightVNC website and the VNC website.  For my purposes (remote administration), I do not want more than one user logged in at a time, nor do I want to share a desktop.  This is how you can disable session sharing:

When starting the TightVNC server, use the -nevershared option.  This will ensure that only one remote client at a time can run a session.  
[vncuser@rat vncuser]$ vncserver :64 -depth 8 -geometry 800x600 -name RAT -mysql -nevershared

Unfortunately, any new session will automatically kick off the current session.  If you don't want this to happen, add the -dontdisconnect option:

[vncuser@rat vncuser]$ vncserver :64 -depth 8 -geometry 800x600 -name RAT -mysql -nevershared -dontdisconnect

This will make sure that one, and only one, VNCviewer will be attached to the VNCserver at any given time, and the session cannot be terminated by another incoming session to the same display.
Finger, who, and w:

One interesting thing to note is that the finger, who, and w commands will not display a user logged into the server via TightVNC.  This is unfortunate, because it makes it more difficult to find out who is on your system at any given time.  If you only use TightVNC for administrative purposes, this should not be a problem, though.
To summarize the security angle:  

If you are going to use TightVNC, make sure you understand how it works, and configure it properly so that it is not easy to abuse!

TightVNC over SSH Setup Summary:



WAN

Server:   vncserver :64 -depth 8 -geometry 800x600 -name LAB -mysql -nevershared -dontdisconnect
Viewer:  vncviewer -encodings Tight -depth 8 -quality 1 -via 8.4.33.4 mysql:64

LAN

Server:  vncserver :64 -depth 16 -geometry 1024x768 -name RAT -mysql -nevershared -dontdisconnect
Viewer:  vncviewer -encodings Hextile -depth 16 -via 192.168.1.2 mysql:64
               - or -
Viewer:  vncviewer -depth 16 -via 192.168.1.2 mysql:64   (This will use Tight encoding with default quality and compression)



Don't forget to set up your $VNC_VIA_CMD environment variable as necessary!

Conclusion:


TightVNC is a flexible, useful tool for remote desktop computing.  Coupled with SSH, it allows you to work securely.  It excels in the role of allowing a complete GUI desktop environment to be accessed over the WAN (even trans-oceanic Internet WAN links).  Based on my experience with using TightVNC over SSH and X over SSH, I would recommend that when you need to run a GUI app over the network:

-  use X over SSH on the LAN side (10 Mbps and up)
-  use TightVNC over SSH on the WAN side (< 10 Mbps links, such as T1, ISDN, and dial-up)

I would not view TightVNC over SSH as a terminal server solution for supporting lots of clients, there are better ways to do that.

TightVNC really shines as a tool for system administrators and network engineers;  that is where I would use it.

Have fun!




Reference Links:

Virtual Network Computing homepage

TightVNC homepage

OpenSSH website

Another Linux-to-Windows interoperabilty tool you may want to check out is rdesktop.  It allows you to connect to a Microsoft Windows Terminal Server (WTS) from a Linux host using the RDP protocol.






Back to Linux Gouge