Accessing your desktop remotely is a convenience that we all appreciate. Many people set up VNC Server and an associated client in order to have their full ‘X’ capable desktop with them wherever they have a network connection. What some do not realize is that VNC as a protocol is extremely insecure and very susceptible to MitM snooping (Man in the Middle) since much of the text back and forth between client and server is transmitted as clear text. Today we are going to install and configure a simple VNC Server, access it with a VNC client and then add some security by using it over SSH.
Simple Server Setup
We are going to use ‘tightvncserver’ to get ourselves up and running:
sudo apt-get install tightvncserver
Next, we need to set an access password for the vncserver once we start it up:
Will prompt us for a password. Note that the current version of ‘tightvncserver’ will automatically truncate any password entered here to eight characters (yet another reason we need to add security to our connections). You have the opportunity to set a second password that will allow ‘view only’ access to the desktop, pressing ENTER here will disable that function.
If you tried to start the vncserver right now, it would start with the default built ‘xstartup’ script created in the ‘/home/user/.vnc’ directory. However, it would be a mess. Unity is not supported in 3D mode in VNC, so you end up with a desktop that is empty (no menu bar, no side bar). We can fix that easily enough as so by installing:
sudo apt-get install gnome-session-fallback
This will enable the session type of ‘gnome-classic’ in our configuration. So, edit your /home/user/.vnc/xstartup file and make sure it looks like this:
# Uncomment the following two lines for normal desktop:
gnome-session –session=gnome-classic &
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
#x-terminal-emulator -geometry 1280×1024+10+10 -ls -title “$VNCDESKTOP Desktop” &
Finally, we can start our vncserver at the command line:
You should see a few lines of text, which will include the message “New ‘X’ desktop is HOSTNAME:1” although the ‘1’ may be another number depending on your local configuration. Now, lets connect to it.
Simpler Client Setup
Let’s install a simple VNC client to connect to our newly minted VNC server, our command is:
sudo apt-get install xtightvncviewer
This will install the package and create some shortcuts so we can use a common command to connect. Easiest way is to connect to our server is to bring up the client:
Which will give you this:
Supply the connection information in the format of “X.X.X.X:5901” if by IP or “NAME.DOMAIN.COM:5901” if by name. Note that your port designation may be different depending on your configuration (and will be clear from your launch of the server above, you will see the ‘X’ server designate with :1 or :2 which is appended to the default base port of 5900, so launched on :2 would be port 5902).
Once you enter the address and port, you will be prompted by another window for the password you set earlier and you should see something like this:
Securing Our Setup
Now, for all the reasons discussed earlier, we do not want to open a hole in our firewall to port 5901. Not only is VNC insecure, it is a commonly known set of ports that gets hammered on constantly looking for access, particularly since the passwords are restricted to eight characters.
Fortunately, if we have to have GUI access to our desktop or server systems remotely, accessing it through SSH is a much more secure (encrypted) method. We simply have to do a little port redirection:
ssh -L 5901:127.0.0.1:5901 username@remotehost
Then fire up another shell on your client and type:
Huh? That looks like I am connecting to my local system you say? Well, you would be right. The first command tells your system to create an SSH tunnel from your local port 5901 to port 5901 on the ‘remotehost’ connecting as ‘username’. This secures and encrypts all the ‘forwarded’ traffic over SSH (the same was a ‘x-forwarding’ can let you run a remote gui command locally).
As we have discussed in previous articles, security is important and never gets enough attention. The more layers of encryption and abstraction between and end user and the system(s) being accessed, the better it is for you and your organization. In this case where you may be accessing your home system remotely, you can expose SSH without the compromises that come from VNC alone.
Of course I would always recommend you set up a VPN solution for connecting to your desktop or server from wherever you are from, however, incoming VPN is restricted by many ISPs where SSH is generally left alone. As long as you keep your system patched and enforce a good password security policy (one that makes brute force password attacks take such a long time they are abandoned), then this setup is a good compromise.
Once you are confident in your configuration, you can simply add the ‘vncserver’ service to your /etc/rc.d/rc.local file on boot. As always, drop me a comment or share your experience.