VNC Qref

Contents

• Introduction
• Basic VNC Use
  • Starting the Server
  • Stopping the Server
  • Running the client
• Advanced Use
  • Setting up your X Session
  • Multiple Clients
• VNC Security
  • Basic SSH Tunneling
  • F-Secure: An Example

Introduction

N.B.: With the new firewall setup (July 2, 2001), incoming VNC connections to the CS department machines from machines outside the department are disallowed. However, connections may be made from CS machines to other CS machines or may be tunnelled through SSH. For more information and instructions regarding tunnelling VNC connections see the security section of this document.

VNC is a very flexible window and desktop sharing and remote access tool which is installed on the CS cluster. It allows you to run X-windows applications from Windows or MacOS, and X applications from Windows, to move from one machine to another without ending your X session, and even display one X desktop on multiple machines. Typical uses for this might include a student who wants to access X applications from her dorm PC, a user who wants to run a long job without occupying a terminal for that time, or a professor who wants to do a demonstration for an entire class in the graphics lab or the terminal room. This document provides a brief introduction to using VNC on the CS department Unix systems. For full documentation, see The VNC Homepage.

Basic VNC Use

VNC uses a simple client–server model to offer all of these features. The server software runs on the system you wish to access, e.g.: Turing. It acts as an X desktop, communicating with and managing the X applications that you run. However, it does not actually display that desktop. Instead, it communicates with the client(s), which may be on a remote machine, sending raw graphical information to it. The client then takes that information and displays the desktop being maintained on the server. The client sends back mouse information and keystrokes, so that the user can interact with the display. The client is stateless, meaning that it maintains no local information other than the display itself. This means that you can quit the client, move to another machine, start a new client, and continue from exactly where you left off. The server keeps running even when no clients are connected, so a user could start a long-running job, disconnect the client and log out (thus freeing up the terminal), and come back later, when the job is likely to be done.

VNC servers are available for Windows, Macintosh, and Unix X-windows. We will be discussing only the Unix server here. See The VNC Homepage for information on other servers.

Starting the server

VNC is deisgned such that each server represents one desktop. Thus, before you can use VNC, you must start your own copy of the server. (In fact, if you wish to work with more than one X session at a time, you may want to start several servers.)

For the simplest case, to start a single server, just type vncserver on any of the CS machines. This can, of course, be done remotely through an ssh connection. The response will look something like this:

% vncserver

New 'X' desktop is turing:1

Starting applications specified in /home/jdoe/.vnc/xstartup
Log file is /home/jdoe/.vnc/turing:1.log

Stopping the server

To stop the server, simply run vncserver -kill :x to kill the server on display x. For example, if you were trying to stop the server which you started on display 1, type vncserver -kill :1. Remember, this will end your session, killing whatever programs were running in it, and disconnecting all clients still connected to the server. This termination is somewhat abrupt, so it may be preferable to close all programs within the session, exit the window manager, and close the client before doing so.

If you have forgotten the display number, just look at the files in the .vnc/ subdirectory of your home directory. There will be one .pid file for each server you have running, and its filename will tell you the display number.

Running the client

In general, to start a VNC client on another system (or even the same system), just run vncviewer from an X-windows session with the server and display as an argument. (If you can't run that, it might be called xvncviewer.) Next suppose, for example, that you have started a VNC server and been told “New 'X' desktop is turing:1”, you could connect to it by running vncviewer turing:1. (If you just type vncviewer then you will be prompted for the server to which you wish to connect.) Next you will be prompted for the password you gave when you started the server. If you give the correct password, it will bring up a window displaying the server X session, which you can interact with as though it were a local session. You can access the viewer's options (such as full-screen mode) with the F8 key. You can quit the viewer at any time without interfering with the server session. As far as the server is concerned, when you quit the client it simply means that you have stopped typing or moving the mouse—you can pick it up where you left off from another client later, and it will continue running any programs you may have started.

Other clients

VNC clients (and servers!) are available for Windows, Macintosh, Java, and Windows CE, in addition to Unix. They are available from the VNC Homepage along with documentation. Any of these clients can connect to a VNC server running on any of the CS machines.

If you do not want to install a VNC client on your own computer, you can use a web browser and the java-based client which is available on Turing. To do this, first run vncserver which will tell you which display number you are running on. Then point your web browser to http://turing.cs.hmc.edu:x, where x=5900+your display number. Thus if your display number were 10, you would go to http://turing.cs.hmc.edu:5910.

Advanced Use

Setting up your X session

The default VNC server session is a very minimal session with a single xterm in the twm mindow manager. You will probably prefer to use a more extensive X session. The simplest approach is to make your VNC startup file a link to your normal X startup file. This is done as follows:

1. Move into your vnc configuration directory ( cd ~/.vnc)
2. Delete the startup file which is already there (rm xstartup)
3. Make a link to your normal X startup file (ln -s ../.xinitrc ./xstartup)
4. Switch back to your home directory (cd)
5. Make your .xinitrc file executable (chmod u+x .xinitrc)

Of course, you can also create a custom startup file if you prefer, by editing .vnc/xstartup. You will need to see other documentation for information on how to do this.

An important note to bear in mind is that screen savers are generally very bandwidth-intensive and wasteful over VNC, so you should probably disable screen savers in your VNC X configuration. Correspondingly, you should not use the xlock program, unless it is configured to use only very simple screensavers. Of course, with VNC, there should be no need to use xlock, since you can achieve the same result by simply quitting the client.

Multiple clients

Normally, when a client connects to a server, all other clients are automatically disconnected. This makes sense—all kinds of chaos can result from two people trying to control a single display, with a single (virtual) keyboard and mouse. However, if these people are willing to cooperate, it can sometimes be advantageous to have more than one client. This can be enabled from either the client or the server end.

On the client end, to prevent a forced disconnect of the other client(s), start the client with the shared option. On the server end, start the server with the alwaysshared or nevershared options to either never or always (respectively) disconnect the old client(s) when a new client connects. In addition to shared on the client, you may wish to use the viewonly option. When this option is used, the client may only view, but not interact with, the server display. This would be useful for class demos and the like. Unfortunately, there is currently no way of forcing clients into this mode—they must accept it voluntarily.

VNC Security

Using VNC does raise some security issues. The VNC session is not encrypted, or authenticated once the password is confirmed, so your session could potentially be spied on or even hijacked—obviously a security risk, since this gives the hijacker free run of your account, and may permit them to break into other accounts, including the superuser, with relative ease.

To prevent any of these problems, we have blocked unencrypted VNC connections from outside of the department. Fortunately, it is not difficult to “tunnel” your connection securely.

Basic SSH Tunneling

Many TCP based applications, such as VNC, are inherently insecure. They are susceptible to many attacks such as “sniffing” and “man-in-the-middle” attacks. SSH protocols take many security precautions to prevent such attacks and are generally considered to be much more secure. Many SSH clients also provide “tunneling” of insecure communications between the client and a remote SSH server. (Many SSH servers also can provide server-to-server tunneling) This is sometimes called port forwarding because the client listens for traffic on one port and securely forwards it to another remote port.

Much of the confusion involved in SSH tunneling comes from uncertainty about which ports to use. When the vncviewer asks for a VNC server to connect to, it is really asking for a socket, i.e.: a hostname/port number combination, such as hostname:portnum where hostname is the host name and portnum is 5900+x. This means that when you set up your SSH Tunnel you will want to connect it to remote port 5900+x. But you will also want to listen at a port which your VNC client will consider pa valid VNC port. We will use port 5903 for example, but any port number from 5900 to 5999 will suffice. Once you have created the local tunnel from local port 5903 to the remote port 5900+x on turing, you will need to point your vncviewer at your local port 5903. The hostname will be localhost. You will then need to point your viewer at localhost:3. (Had you used a port other than 5903, you would need to use the last digit or two of that port number.)

In other words: If you are sitting at a UNIX-like system and have a VNC server running on display 3 on Turing, the following should work:

% ssh -L 5903:turing.hmc.edu:5903 jdoe@turing.hmc.edu
% vncviewer localhost:3

If you want to use the web client to connect to your vnc server then you simply have to start a tunnel from port 59xx on your computer to port 59yy on Turing, where yy is as defined above. Then instead of pointing your web browser at http://turing.cs.hmc.edu:59yy, simply point it at http://localhost:59xx.

If you are using a Windows machine, you have two choices of program: you can use F-Secure (which is provided by CIS) or PuTTY.

F-Secure

Let's run through the entire process of starting a VNC server and then tunneling a connection to the server through SSH.

1. We begin with a command prompt on Turing:

   % vncserver
   
   New 'X' desktop is turing:2
   
   Starting applications specified in /home/jdoe/.vnc/xstartup
     Log file is /home/jdoe/.vnc/turing:2.log
   

2. Next we need to make a SSH tunnel to port 5902 on Turing. Begin by opening F-Secure.
   
3. Click Cancel when it asks you for logon information and go to Edit and then to Properties.
   
4. In the window that appears, on the left hand side, go down to Tunneling and go to Local Tunneling. Click "Add"
   
5. Source Port is the port on your machine that you want F-Secure to listen on. Again let's make it 5900 (although it could be any number from 5900 to 5999). Destination Host is turing and Destination Port is 5902. Click OK.
   
6. Click OK again. F-Secure needs to be connected to Turing for the tunnel to become active so go ahead and connect to turing.
   
7. Finally start your VNC client (there is one of those on Kato also—it is called vncviewer) and tell it to connect to localhost (localhost:0 would also work). If you are using the web client, point your browser at http://localhost:5903.
   

When you are finished remember to disconnect your SSH session as well as the VNC session, or simply close the SSH client and this will terminate the VNC client as well. When you exit F-Secure it will ask you if you want to save the changes you made. Say yes and put the file somewhere where you can access it easily. Opening it instead of F-Secure will prevent you from having to reconfigure the tunnel everytime you want to use it.

PuTTY

1. We begin with a command prompt on Turing:

           % vncserver
   
           New 'X' Desktop is turing:3
       

2. Open PuTTY, and in the "SSH" menu, select "Tunnels".
3. Put the desired port on your machine in the "Source Port" box.
4. Put the following in the "Destination" box: turing.cs.hmc.edu:59xx, where xx is the number of your VNC session. In our example, this becomes turing.cs.hmc.edu:5903.
5. Click the "Add" button.
6. Click on "Session" at the top of the menu and contiune as usual.
7. Once you have logged in, open the VNC viewer on your machine and point it at localhost:port you selected in step 2. For example, if you put "5903" in the "Source port" box, you would point your viewer at localhost:5903.

For more info on SSH tunneling there is a Quick Reference on it here. There is also a page specifically on tunneling VNC connections on the VNC website.

Copyright (c) HMC Computer Science Department. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License.''