I’m re-doing an old site and wanted to rescue this page from it because although it’s a bit old, I think it’s worth preseving these “how-to” pages on the internet because there might be, somewhere, sometime, someone doing the same kind of thing and might find this useful, who knows…
Recently, I needed to set up a computer running Linux (Ubuntu, Gutsy Gibbon), so that it could be remotely controlled from a Windows laptop. The box was going to be disconnected from its keyboard, mouse and monitor, so all the screen output and all the keyboard and mouse input would have to go through Windows too. Ideally, an authorised user should be able to use the “headless” machine as if he or she were actually sitting in front of it even though, in reality, it was hidden away in a cupboard out of the way. At the same time, it was essential that non-authorised users should be shut out completely.
I found the online documentation good but widely dispersed, and I had to hunt around and ask a lot of questions to finally get all my
penguins ducks in a row, so I thought it would be a good idea to collect it all in one place for the benefit of anyone else who might be trying to achieve the same thing.
What is VNC?
VNC is a remote-control device for computers. You might have seen it – or variants of it – if you’ve ever had your computer repaired by someone using a remote control/remote desktop connection to take control of your mouse cursor and make changes that way. It’s really helpful if you want to be able to run more than two computers but don’t necessarily have space for both in the office. One can go in the cupboard under the stairs but you can still use it by simply opening up a new window on the other using VNC.
So what’s the catch? Well, there’s a pretty obvious one in that it allows you so much control that if you just leave it open for anyone to access then someone might be able to take over the machine and do pretty much whatever they like with it. In this discussion, the method I’ll be using hinges on forcing VNC to only accept connections if they come through a secure IP tunnel
OK, So What’s an IP Tunnel?
VNC uses port 5900 by default, but there’s another protocol, Secure Shell (SSH) that uses port 22. IP tunneling allows the user to set up a connection via secure shell, which is encrypted and can be set to use string authentication methods. The VNC traffic is then siphoned down the SSH connection, where it’s sent back up to 5900, so you get exactly the same benefits but it’s all rock-solid secure.
Before You Start
Firstly, I find wireless connections a bit ropey on ubuntu, and since the network is going to be the only way in, make sure you have a decent wired connection to fall back on or you’ll risk being locked out by an update or a change in config.
Secondly, VNC – for some reason will fail (because X will fail) if the monitor and keyboard aren’t plugged in using default settings on Ubuntu. In other words, if you’re starting with a headless box, it may be hard to test some of these changes. This is dealt with in this article, so you could skip ahead to the “Going Headless” section or you could just borrow some I/O devices so you can check the progress as you go along and debug things.
Thirdly, remember you’re changing important system files here, and we can’t be held responsible for anything that might go wrong along the way, so it’s your responsibility to take normal precautions to back everything up properly and have an exit strategy if it doesn’t turn out the way you expected.
And lastly, I’m assuming SSH is to be the only way in. If you’re running a telnet server as well it will potentially open another security hole, so you may want to consider what to do about that…
The VNC Server
To begin with, Ubuntu’s default VNC server, Vino, isn’t so hot and doesn’t start working till after you’ve logged in. There are plenty more available but I found X11vnc the best for what was needed for various reasons. There are some good instructions on this page from the Ubuntu Forums (jnorth’s post, half way down) but the author’s configuration must be different from mine because some of the file paths weren’t right. The order I used was:
1. Switch to the correct server. Enter each of the following two lines at the console and follow the on-screen prompts
sudo apt-get remove vino
sudo apt-get install x11vnc
2. Set a password for VNC. This will actually be one of three passwords you’ll need to use to access the box, so if you want to skip this stage as overkill, feel free!
sudo x11vnc -storepasswd
3. Make new configuration settings for Gnome
sudo gedit /etc/gdm/gdm.conf
and change #KillInitClients=true to KillInitClients=false
4. Add vnc to gdm’s initiation script
sudo gedit /etc/gdm/Init/Default
and add the following line (all on one line!) at the top, directly after the opening comments
/usr/bin/x11vnc -rfbauth /etc/vnc.passwd -noxdamage -forever -bg -o /var/log/x11vnc.log -rfbport 5900 -localhost
Note that at this point, you still don’t have a working vnc server. If you are planning to test vnc is working correctly before setting up ssh, you need to temporarily remove the -localhost from the end of that line and restart the machine because its purpose is to block external connections so that users have to be logged in via the secure shell before they can start work.
The SSH Server
1. To set up the SSH server on the headless machine type the following at a command prompt:
sudo apt-get install openssh-server
2. Then update the configuration
sudo gedit /etc/ssh/sshd_config
and check you have the following settings in the relevant parts of the file:
PubkeyAuthentication yes (should be like that already, but if it isn’t, change it!)
HostbasedAuthentication no (ditto)
3. Bounce the server with
4. Now let’s make some keys. Summon the resident locksmith with…
ssh-keygen -t dsa
which will prompt you for a file location (use .ssh/id_dsa) and a passphrase. This will be something you need to type in each time you connect to the box. You’ll recall I mentioned there were three passwords needed? Well, this is another, so again, if you think this is overkill you can skip it but you run the risk that anyone who gets access to your key (say by finding a thumb-drive you’ve left lying around) will have direct access to the server.
5. Navigate to the .ssh folder in your home directory and make a copy of id_dsa.pub with the filename authorized_keys then copy id_dsa to the client machine so it can be used by whoever is logging in.
[Addendum] – SSH in Hardy seems to have rsa configured in as standard so you could try substituting “rsa” in place of “dsa” in steps 4 and 5 to make this bit work in Hardy.
Setting up SSH on Windows
1. First of all, you need two programs: Putty and Puttygen. The former is a Secure Shell Client and the latter is a key generator. Both are available for free download from the Putty download page.
2. Open Puttygen and go to File>Load Private Key. Browse to where you saved id_dsa. Enter the passphrase (assuming you used one!) and click “Save Private Key” to save it in some unobtrusive location. You should make a backup of the key in case you lose it , but obviously make sure you keep both copies secure!
3. Now open Putty and make the following changes:
Enter the name or IP of the host computer under “Host Name (or IP Address)”. The port number should be the default 22 unless you consciously changed it.
The protocol is SSH of course!
Use the tree menu on the left to get to Connections>SSH>Auth and click the “Browse” button to browse to where you saved the key file.
Again, in the tree menu, click on “Tunnels”.
Under “Add a new forwarded port”, add the following settings:
* Source Port: 5900
* Destination: Localhost:5900
* (Radio Button): Local
…and click “Add”
Now, using the tree menu again,return to “Session” at the top. Enter a name for the saved session – e.g., VNCTunnel, and click “Save”.
If all has gone according to plan, you should now be able to connect to your server to make sure everything works properly before you actually take the step of removing the I/O devices. If you don’t have any I/O devices and have been following the above using a terminal, see the “Going Headless” section below for the final configuration changes you’ll need to make before X will agree to play nicely with your VNC server.
1. Start by restarting the Linux box, just to make sure any changes you’ve made are picked up.
2. While that’s going on, download tightvnc from the tightvnc web site. It’s a handy little gizmo that works without even needing to be installed.
3. When you’re ready, open Putty, select your stored connection, VNCTunnel, or whatever you called it, and click “Open”. Enter your username (the username on the linux box whose home directory contains the public key for openssh) followed by the passphrase for your private key.
4. Now open tightvnc. The vnc server to use is localhost:0 (NB – not the address of the actual host. SSH is passing the data back and forth through the tunnel!). Then enter the password you used for vnc. If you don’t get prompted for a password then something went wrong! Finally, log into gnome.
Switching User Accounts
Note that you only have to establish the SSH connection once under one username and you’ll then be able to log into the box as often as you like, under any other username using the gnome desktop manager just as if you were sitting at the machine itself. However, I’ve found that the user switcher applet tends to fail, so you will probably find it’s best to log out as one user before logging in as the other.
This is potentially tricky because it involves editing the display settings in xorg.conf, and the settings vary from machine to machine, so your changes may need to be different from mine.
1. To be safe, back up the file before starting so it can be restored in an emergency. In the command window, type
sudo cp /etc/X11/xorg.conf /etc/X11/xorg.bak
2. Edit the X settings. This next line uses a command-line text editor since that might be all you can access if you’re shut out of Gnome at this point!
sudo nano /etc/X11/xorg.conf
3. Scroll down to the section which reads
(which may or may not have some other lines in between the first and second), and either add the following just below it
Option "AllowMouseOpenFail" "true"
…or, if you already have a section entitled “ServerFlags”, just add the second line somewhere inside the existing section.
4. According to the x11vnc FAQ‘s that should be enough but I found my x server wanted to go into low graphics mode because it couldn’t determine what resolution to use, which meant I was still unable to access vnc, so I also had to go down to the “Screen” section of xorg.conf and remove all screen the resolutions except the one I wanted to use. In other words:
<blah blah blah>
which did the trick.
[Addendum] Later, when I tried this same process on a differengt computer with a different (nvidia) graphics card, I found the vnc session would always default to 640×480 resolution if I started it with no monitor present. Switching from the proprietary driver to vesa helped a bit (800×600!) but I needed to be a bit more specific to get it the way I wanted, by setting refresh rates and passing some parameters to the device driver as well as stating a preference for the screen size. I’m sure there will be a lot of variation between graphics cards (in fact, I know there is because I googled it!) but here’s what I used for my Device, Monitor and Screen settings which seemed to work:
Identifier "Configured Video Device"
Option "NoDCC" "True"
Option "IgnoreEDID" "true"
Identifier "Configured Monitor"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
Linux being a pretty eclectic creation, you’re more than likely to find that some aspect of your setup details will differ from what I’ve written above, but don’t be put off because whatever your problem you can be sure someone will have had the same one before, and Google will be able to help of you make your query specific enough. Please let me know if you have anything to add or any questions to ask.
Thanks – and good luck!