You are here

vncserver - a remote desktop alternative

Printer-friendly versionPrinter-friendly version

Running a VNC X server on your desktop

The simplest way to connect to a graphical DICE desktop remotely is to use the RDP based remote desktop service:

However an alternative technology exists - VNC - and this page will show you one way to use it to connect to a graphical desktop running on your normal DICE machine. It is not particularly user friendly, and it does not work well with our authenticated filesystem, AFS.

A certain amount of technical knowledge is assumed, and this is not a step-by-step list of instructions.

The basic principles

  1. Start a vncserver process on your DICE desktop.
  2. ssh tunnel port 5901 from your home machine to your DICE desktop.
  3. Use a VNC client on your home machines to connect to localhost:1.

An ssh tunnel is needed for security, because VNC does not support an encrypted connection natively. If you were to connect directly to your DICE desktop, then potentially a man-in-the-middle could intercept your keystrokes and view your remote machine.

Note that this connection will only last about 18 hours before your kerberos and AFS credentials expire and VNC ceases to function correctly.

More detail

For the sake of this page, your "home machine" is the computer you are physically using, at home or on a train for example; and "your DICE desktop" is typically the physical machine in your office in an Informatics building - the machine that you would normally login to.

To remotely start the vncserver process on your DICE desktop, you need to ssh to your desktop. To do this, first connect your home machine to the Informatics network using the the Informatics OpenVPN.

Once your OpenVPN is connected, then you can ssh directly to your DICE desktop. If it has gone to sleep, you can wake it:

As you ssh to your DICE desktop, you should also tunnel local port 5901 to port 5901 on your DICE desktop. For a DICE desktop called booboo a typical command to run on your home machine would be:

  ssh -L 5901:localhost:5901

where UUN was your Informatics username. Graphical ssh clients, for example PuTTY, will have ways of achieving the same effect.

Set a VNC password

Now that you have a shell on your DICE desktop, you should set a VNC password if you haven't already done so. You only need to do this once (or any time you want to change the password). Run vncpasswd. You will be prompted to set a password that will be used later when you connect. You should not use a valuable password, as it is not stored or transmitted as securely as it could be.

You will also be asked if you want to create a "view-only" password - you can answer "n" to this.

neilx@booboo> vncpasswd
Would you like to enter a view-only password (y/n)? n
A view-only password is not used

You should now have the file ~/.vnc/passwd in your home directory. Now might be a good time to check the AFS ACLs on your ~/.vnc directory - it should only be readable by you and "system:administrators". The man pages for fs_getacl and fs_setacl will help with this.

Create your xstartup file

vncserver will simply start an X server, but without a window manager, it's not likely to be of much use. Create/edit the file ~/.vnc/xstartup with at least these two lines:


Then make sure it is executable:

chmod +x ~/.vnc/xstartup

Again, once this file has been created, you won't need to do it again.

Starting your VNC Server

Once your password and startup script are configured (see above), then on your desktop you could simply run the command vncserver. You should then get a message along the lines of:

neilx@booboo> vncserver

New ' (neilx)' desktop is

Starting applications specified in /afs/
Log file is /afs/

Note if you see a number other than ":1" after your hostname, then you have probably started another instance of the server, when there was already one running. You can list all your running servers/displays with:

neilx@booboo> vncserver -list

TigerVNC server sessions:

:1              17486
:2              17796

This isn't necessarily a problem, but you will need to adjust the ssh port forwarding if you want to connect to display :2, as it will be on port 5902, and so on.

Our use of AFS and Kerberos will mean your server will only remain running for as long as you keep the shell open and renew your credentials (every 18 hours). This might be fine, but if you are starting the server remotely (via ssh) and your connection drops, your VNC server will drop too. You may be able to rescue it if you still have a working shell via the VNC client - type renc to renew your credentials.

Connecting to your VNC desktop

At this point you should have a VNC server running on your DICE desktop, waiting for a client to connect to it. You need to use a VNC Viewer to connect to your VNC server. Several clients exist for various platforms, for example or Some are free, some have paid for versions. macOS has a builtin viewer.

In theory you could connect directly to your VNC session using its hostname and display :1 or port 5901, but as mentioned previously, the network traffic would be going unencrypted between your DICE machine and (in this case) the OpenVPN endpoint. Though it isn't recommended, it could be a useful debugging step if you don't think the ssh tunnel is working.

So the recommended machine to connect your client to is "localhost" and display ":1" (or port 5901). So on a Mac for example you could go to Finder -> Go -> Connect to Server and in the Server Address, enter vnc://localhost:5901 .

Using TightVNC you'd enter the Remote Host as localhost:1:

When you connect, you should be prompted for a password. This will be the password you set with vncpassword above, not your DICE password.

Having said that, once you successfully connect, you may then see a desktop screenlock, with your UUN, in which case you would enter your DICE password to unlock the remote VNC desktop.

You should now see a desktop similar to the one you get if you use the RDP service. If you wanted to use a different Window manager, then you could change the mate-session line in your ~/.vnc/xstartup file to /etc/X11/xinit/Xsession gnome & for gnome or /usr/share/defenv/fvwm2/fvwm2.inf & for fvwm.

Ending your session

Once you have finished you can disconnect your VNC client, and then return to a shell on your DICE desktop and issue the command:

vncserver -kill :1

This will stop the vncserver and remove the risk of anyone else trying to connect to it. Note this will also close any Windows or applications left running on the remote desktop.

As mentioned before, if you don't kill your session, and (for example) leave it running overnight, you'll find you'll not be able to reconnect in the morning, as your kerberos and AFS credentials will probably have expired.

You will have to ssh to your DICE desktop and kill the running process and then start a new one.

More details

For more advanced use of vncserver, see the man page. For example you can specify the size of the desktop in pixels at creation time, rather than default of 1024x768.

You can add other commands to the xstartup file to automatically start shells, or xclock, xeyes etc.

Native Encryption

It is actually possible to enable a native TLS and x509 authenticated VNC connection, thus removing the need for the SSH tunnel, but it requires some setup, and a VNC client that supports TLS and x509. The TigerVNC client should, but at the time of writing the 1.10.1 client has a bug in it which means it doesn't work. The nightly release version has the bugfix, and does work.

The basic pointers are:

  1. Create an X509 certificate and key file. I copied /etc/pki/tls/certs/make-dummy-cert into my own area, modified it to create a certificate with my hostname in it.
  2. Create/edit your ~/.vnc/config file with lines similar to:

    Setting that securitytype will only allow secure connections, so clients that don't support X509 will be unable to connect.

  3. (Re)start vncserver
  4. Use TigerVNC viewer 1.10.80 or greater, with encryption enabled to connect directly to . When you connect you'll be asked if you want to trust the unknown certificate. At this point you should check changes you made to the subject, location, etc to the certificate are reflected in this popup.

See also our guide to the related x11vnc command, Using VNC.

Last reviewed: 

System Status

Home dirs (AFS)
Other services
Scheduled downtime

Choose a topic