Description¶

This page gives the instructions for setting up VNC to communicate over TLS.

The paths given are from Fedora 13 & RHEL 6, so any system paths may be different on other Linux distributions. The per-user paths will likely be the same regardless of distribution.

TLS should be set up on the servers first¶

Before using TLS to connect to virtual machines, their host servers must be configured for TLS.

The steps for doing this are fully documented on the TLS Setup page

What you will need¶

Once the host servers are set up for TLS (and verified), the client set up is fairly straightforward.

You will need:

1. A Certificate Authority "Certificate" file

2. A "Client" Certificate file, signed with the above Certificate Authority Certificate

3. The private key for this Client Certificate file

Creating these files isn't too difficult. The steps to follow are listed on the previously mentioned TLS Setup page

The paths to install the files at are listed below. In addition, all of the working VNC clients can accept an optional Certificate Revocation List (CRL) file. This can be either in a system wide path, or in a per-user location:

• System wide location: /etc/pki/CA/cacrl.pem

• Per-user location: $HOME/.pki/CA/cacrl.pem

Security¶

Be careful when using system wide client certificates. Any user with read access to a client certificate + private key can use it to authenticate to your (configured) virtualisation servers. So, if you have permissions allowing wide read access (ie 644) to those files on a client system, any user with login access to that client system can then perform admin commands on your virtualisation servers. That may not be what you want. Use good unix security (groups, permissions, acls, roles, etc) to manage access to the certificate + private key.

Changes to be made on the virtualisation host server¶

(please note these are Fedora 13 & RHEL 6 specific paths, other distributions may vary)

1. You need to enable some settings in /etc/libvirt/qemu.conf on the host server.

   1. Instruct QEMU virtual machines to listen for incoming connections

      vnc_listen = "0.0.0.0"

      0.0.0.0 instructs QEMU to listen on all network interfaces. You can give a specific IP address instead if required.

   2. Enable TLS for connections

      vnc_tls = 1

   3. Enable use of X509 certificates for authentication

      vnc_tls_x509_verify = 1

2. Place the TLS Server Certificate and matching private key files where your QEMU user can access them.

   The QEMU process needs read access to a TLS Certificate Authority Certificate, a Server Certificate signed by it, and the private key for the Server Certificate. These must be placed in:

   • Certificate Authority Certificate: /etc/pki/libvirt-vnc/ca-cert.pem

   • Server Certificate: /etc/pki/libvirt-vnc/server-cert.pem

   • Private Key for the Server Certificate: /etc/pki/libvirt-vnc/server-key.pem

   Soft links to the certificates and keys for the main libvirt configuration can be used:

   $ sudo mkdir -m 750 /etc/pki/libvirt-vnc
   $ sudo ln -s /etc/pki/CA/cacert.pem /etc/pki/libvirt-vnc/ca-cert.pem
   $ sudo ln -s /etc/pki/libvirt/servercert.pem /etc/pki/libvirt-vnc/server-cert.pem
   $ sudo ln -s /etc/pki/libvirt/private/serverkey.pem /etc/pki/libvirt-vnc/server-key.pem

   By default on RHEL 6 and Fedora 13+ (older is untested), QEMU processes are launched using qemu:qemu ownership.

   You mush ensure it can read the TLS certificate files. If you used soft links as in the example above, one way to achieve this is:

   $ sudo chgrp qemu /etc/pki/libvirt \
                     /etc/pki/libvirt-vnc \
                     /etc/pki/libvirt/private \
                     /etc/pki/libvirt/servercert.pem \
                     /etc/pki/libvirt/private/serverkey.pem
   
   $ sudo chmod 750 /etc/pki/libvirt \
                    /etc/pki/libvirt-vnc \
                    /etc/pki/libvirt/private
   
   $ sudo chmod 440 /etc/pki/libvirt/servercert.pem \
                    /etc/pki/libvirt/private/serverkey.pem

3. If you're using Virt Manager or Virt Viewer, you also need to enable a setting in /etc/sysconfig/libvirtd on the host server.

   LIBVIRTD_ARGS="--listen"

4. Restart the libvirt daemon

   $ sudo service libvirtd restart
   Stopping libvirtd daemon:                                  [  OK  ]
   Starting libvirtd daemon:                                  [  OK  ]

5. The VNC TLS setting is only recognised at guest start time, so if you have guests running from before you made these changes, you'll need to restart them for it to be effective.

6. Verify things are correct by connecting to a virtualized guest using one of the VNC clients known to work.

VNC clients known to work¶

$ vinagre hostserver:0

$ virt-manager -c qemu+tls://root@hostserver/system --show-domain-console=4ce376a6-db4a-9382-4f06-03ea4d2f6d0b

$ virt-viewer -c qemu+tls://root@hostserver/system guestname

$ python /usr/share/doc/gtk-vnc-python-0.3.10/gvncviewer.py hostserver:0

VNC clients known to NOT work with TLS (yet)¶

$ ps -ef | grep qemu
qemu     16048     1 18 14:09 ?        00:00:24 /usr/libexec/qemu-kvm -S -M rhel6.0.0
-cpu Nehalem,+x2apic -enable-kvm -m 1024 -smp 2,sockets=2,cores=1,threads=1
-name guest1 -uuid 4ce376a6-db4a-9382-4f06-03ea4d2f8d0b -nodefconfig
-nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/guest1.monitor,server,nowait
-mon chardev=monitor,mode=control -rtc base=utc -boot c
-drive file=/nas/guest1.img,if=none,id=drive-virtio-disk0,boot=on,format=qcow2
-chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb
-vnc 0.0.0.0:0,tls,x509verify=/etc/pki/libvirt-vnc
-k en-us -vga cirrus

# virsh start guest1
error: Failed to start domain guest1
error: cannot send monitor command '{"execute":"qmp_capabilities"}': Connection reset by peer