Setup VNC Server in Fedora
“Virtual Network Computing (VNC) is a desktop protocol to remotely control another computer. It transmits the keyboard presses and mouse clicks from one computer to another relaying the screen updates back in the other direction, over a network.” -WikiPedia-
This article describes in brief how to configure VNC server instances for one or multiple users on a remote machine, how to use VNC to start graphical applications on boot and finally how to enhance security by connecting to the server through encrypted SSH tunnels.
Prerequisites
A user account should exist on the remote machine.
The RPM packages vnc-server and vnc should be installed on the remote machine and your workstation respectively.
Setting up the server
I assume that we have setup a remote user account, named “leopard” and we want to start an X session through VNC for this user.
In Fedora Core or Red Hat based distros in general, all we have to do is define the VNC server instances in /etc/sysconfig/vncservers. These will be started by the vncserver initscript. This has to be done as root. Edit this file so that it contains the following:
VNCSERVERS=”3:leopard”
VNCSERVERARGS[3]=”-geometry 1024×768 -depth 16″
With these we define that a vnc server instance should be started as user leopard on display 3 and we also set some options for this server such as resolution and color depth. Each VNC server instance listens on port 5900 plus the display number on which the server runs. In our case, leopard’s vnc server would listen on port 5903.
For multiple vnc instances /etc/sysconfig/vncservers would look like this:
VNCSERVERS=”1:tiger 2:albatros 3:leopard”
VNCSERVERARGS[1]=”-geometry 1024×768 -depth 16″
VNCSERVERARGS[2]=”-geometry 800×600 -depth 8″
VNCSERVERARGS[3]=”-geometry 1024×768 -depth 16″
These would listen on ports 5901, 5902, 5903 respectively.
User Configuration
There is one more thing that needs to be done on the remote machine. User leopard’s vnc password needs to be set. So, as user leopard give the command:
# vncpasswd
We are prompted for a password. This is the password that we will use when we connect to leopard’s vnc server instance. This password is saved in /home/leopard/.vnc/passwd.
Start the VNC server
After the initial configuration is done we restart the vnc service. As root:
# service vncserver restart
To make VNC server to start on boot:
# chkconfig vncserver on
More User Configuration
After the VNC service is started, some new files are created in /home/leopard/.vnc/ directory. These include leopard’s vnc server log file, pid file and an X startup script. As user leopard we edit the script in order to customize some settings. The default /home/leopard/.vnc/xstartup script contains some commands that are executed when the VNC server is started. These include:
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80×24+10+10 -ls -title “$VNCDESKTOP Desktop” &
twm &
xsetroot in this case sets the background color.
vncconfig is a supplementary program that can be used to control the vnc server. Apart from this, when run without arguments it acts as a helper application and its main purpose is to provide support for clipboard transfers between the client (vncviewer) and the vnc server.
xterm starts an xterm terminal.
twm starts the X server’s default window manager. We probably want to change that to a more user friendly window manager, eg fluxbox.
The VNC server, apart from letting us control a remote machine using a graphical interface, it serves as a way to start graphical applications on boot. For example, I want my favourite p2p program, amule, to start on boot. So, I add this to the /home/leopard/.vnc/xstartup script. This is how my xstartup file looks like:
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80×24+10+10 -ls -title “$VNCDESKTOP Desktop” -e ./menu &
amule &
fluxbox &
menu is a script of mine that is executed when xterm is started.
Remember to put the “&” symbol after each command, so that it goes to the background and the xstartup script continues on.
Restart the VNC service for the changes to take effect. As root:
# service vncserver restart
Connect to the VNC server
In our example, leopard’s vnc server listens for connections on port 5903. So, open this port in the remote machine’s firewall.
We connect to the remote machine using a vnc viewer. Having installed the vnc package, connect to to the server with the following command:
# vncviewer 192.168.0.1:5903:3
The general usage is :
vncviewer [Server’s IP]:[Port]:[Display]
We are prompted for the password and eventually connect to the server. Closing the vncviewer’s window, does not affect the server or the programs we run on it. If we reconnect everything will be there.
Special Note: There is no need, actually it’s pointless and could give you some trouble, to logoff from your remote X session. If this happens, generally you need to restart the VNC service on the remote machine to get your remote desktop back. If you want to stop working on your remote desktop, just close the vncviewer’s window and you are done.
Security
The VNC protocol is not a secure communication protocol. The use of a vnc password provides security at the level of server access (it’s vulnerable to brute-force attacks though), but the whole VNC session is transmitted in the clear, without encryption. The easiest, but most effective, way to secure our connection to the VNC server is to connect through an encrypted SSH tunnel. This way the whole session will be encrypted.
The rest assume that you have the SSH server up and running on your remote machine (server.example.com) and you know what SSH tunnels are.
So, what we are going to do is to create an encrypted tunnel, and connect to our VNC server through it. We also want this tunnel to be automatically closed as soon as we shut down vncviewer. All this is done with the following command:
# ssh -f -L 25903:127.0.0.1:5903 leopard@server.example.com sleep 10; vncviewer 127.0.0.1:25903:3
This is what it does:
•   -L 25903:127.0.0.1:5903 forwards our local port 25903 to port 5903 on the remote machine. In other words, it creates the tunnel.
•   -f forks the SSH session to the background, while sleep is being executed on the remote machine. This ssh option is needed because we want to execute the following command (vncviewer) in the same local machine’s terminal.
•   vncviewer connects to the forwarded local port 25903 in order to connect to the VNC server through the encrypted tunnel.
The sleep command is of major importance in the above line as it keeps the encrypted tunnel open for 10 seconds. If no application uses it during this period of time, then it’s closed. Contrariwise, if an application uses it during the 10 sec period, then the tunnel remains open until this application is shut down. This way the tunnel is automatically closed at the time we close vncviewer’s window, without leaving any SSH processes running on our workstation. This is pure convenience!
Using SSH tunnels to conect to your VNC server has two advantages:
1.   The whole session is encrypted.
2.   Keeping port 5903 open on your remote machine is no longer needed, since all take place through the SSH tunnel. So, noone will know that you run a VNC server on the remote machine.
Further Reading
I recommend that you read the man pages. Everything is in there:
# man vncserver
# man Xvnc
# man vncconfig
# man vncviewer
# man ssh
Creating an ssh tunnel is an unnecessary step. Read the vncview man page section on the ‘via’ option. Running ‘vncviewer -via machine.running.vncserver localhost:2′ will have vncviewer create the ssh tunnel for you. I find it particularly useful for accessing my sessions through a firewall since I can do ‘vncviewer -via
If the -f option is not used:
# ssh -L 25903:127.0.0.1:5903 leopard@server.example.com
We actually create the tunnel, but at the same time we login to the remote shell. In this case, it’s necessary to open another local terminal in order to execute vncviewer. This is unconvenient.
By using the -f option we avoid logging into our remote machine’s shell, so we remain at our local terminal and can execute commands locally. But the use of this option needs one of the following things:
– we have to execute a command on the remote machine, otherwise -f does not work
– or we have to use the -N option together with -f. This way there is no need to execute any commands on the remote machine. This has one major disadvantage which I’ll explain later.
So, the question is “which command should we execute on the remote machine when using the -f option?”. We do not need to start any particular process, we just want to start an SSH tunnel. This is where the sleep command comes really handy, because:
– It does nothing
– It can be set to give us enough time to start another process at our local machine which will use the SSH tunnel.
So, we start the tunnel with the following command:
# ssh -f -L 25903:127.0.0.1:5903 leopard@server.example.com sleep 10
Executing the following command before the 10 seconds pass,
# ps ax | grep ssh | grep -v grep
we see that an SSH process runs in the background. After the 10 seconds pass, the last command shows no output. This means that sleep was executed on the remote machine for 10 seconds and then the SSH process ended, closing the tunnel at the same time.
If we execute vncviewer in a way that it connects to the server through the SSH tunnel before the 10 seconds pass, then the SSH process we had previously started does not end after the 10 secs, because the tunnel it had created is being used by another process, vncviewer in this case.
If we close vncviewer, then the tunnel is not being used any more. The SSH process we had previously started does not have any more jobs to do. It has completed its task, the execution of the sleep command, so it now ends together with vncviewer.
The following command on the local machine confirms that:
# ps ax | grep ssh | grep -v grep
I had mentioned the -N option before. This makes it possible to use the -f option without executing any commands on the remote machine. So, we could have started the tunnel with this:
# ssh -f -N -L 25903:127.0.0.1:5903 leopard@server.example.com
The only advantage of its use is that we can start an SSH tunnel without leaving our current local terminal, so we can execute other commands from our local machine. However, the drawback is that this SSH process runs forever. It would never close automatically, meaning the the user has to kill it. That’s why it’s not convenient.
