Secure Remote Desktop Sharing with VNC on Linux

This article is the second half of a two-part series on secure remote desktop sharing with VNC. If you missed the first part, which appeared Monday on ASP Free, I’d suggest skimming through it, at least. The first part was an introduction to VNC connections and it focused on Windows. This one will get into the depths of configuration, optimization and explain ways to set up and benefit from VNCs on Linux platforms too.

You don’t want to miss this article. Reading it should help you realize the "big picture," and that the key terms, methods and techniques will fit into a whole just like puzzle pieces. The language of this part might be a bit more advanced but I’m trying to give you tons of real-world examples and instructions. Nonetheless, I’m sure that your level of experience and knowledge with Linux operating systems will be more than enough.

Before moving on, I’d advise checking your firewall settings (both software and hardware, if there are any), configure your router’s SSH port forwarding, and make sure you have an SSH server up and running. If you don’t, then head over to OpenSSH and grab it. Throughout this article I will assume that the reader has SSHd (daemon = server) and has no router and/or firewall related issues. The purpose of this article is to focus mainly on VNC.

Installing and Running TightVNC with SSH Tunneling

 Every now and then installing a new application might become tricky, especially if we want to install a somewhat secure server. Throughout this section I’m going to lead you through the installation process of the TightVNC Server and then we’re going to secure it via the famous SSH tunneling technique.

Considering that you’re running Linux you should be already familiar with installing and configuring applications on this OS. Depending on your distribution some of the commands and paths might change; in that case, all you need to do is customize them as required. You’ll get the drift.

Why TightVNC you might ask? It’s simple. We already discussed in the first part that not all of the VNC clients have server-side. My personal favorite is TightVNC. It has a lot of advantages, performance optimizations and enhanced features compared to the standard VNC (i.e., efficient compression algorithms, configurable compression levels, optional JPEG compression, enhanced web browser access, flexible configuration options and automatic SSH tunneling on UNIX-that’s what we need).

Visit this link and download the latest release of TightVNC for Linux. Currently, at the time of writing this article, the ‘1.2.9-1‘ version is the latest. For beginners I’d really suggest downloading the RPM package. In that case you should download "tightvnc-server-1.2.9-1.i386.rpm." Log in to ‘root’ or a specific ‘VNC user‘ and get ready!

{mospagebreak title=Getting Started}

First we need to make sure that no previous VNC packages are installed. Running the command below uninstalls the specified package. Usually two packages are already installed, and these are vnc and vncserver. Try the command below for these two.

rpm -e name_of_the_package

Then go to the folder location where you’ve downloaded your new TightVNC RPM. Run the following command to install:

rpm -ivh exact_name_of_the_package_goes_here                

If you are in a rush and don’t like using the TAB auto-completion you might run the following command instead of the previous one:

rpm -ivh tightvnc*rpm

If the installation ends successfully you should see the following lines or something similar:

Preparing…                ########################### [100%]

   1:tightvnc-server        ########################### [100%]

Next you need to actually run the server. Type the following command:

vncserver :1 -geometry 1024×768 -depth 16

When you run the command, it’s going to ask for a password. Decide whether or not you want to use a separate view-only password. You should just type in the password you desire and then hit enter. Of course, running "vncserver :1" is enough but this way you have the ability to customize and add advanced options. Check out the way it starts up.

You will require a password to access your desktops.

 

Password:

Verify:

Would you like to enter a view-only password (y/n)? n

 

New ‘X’ desktop is localhost:1

 

Creating default startup script /root/.vnc/xstartup

Starting applications specified in /root/.vnc/xstartup

Log file is /root/.vnc/localhost:1.log

Notes:

  • ":1" is the display ID. The number 1 is just an example. The ports that will be open and allocated by the VNC server are the following: 5801, 5901 and 6001 (that’s if the # is 1, otherwise it’s 5800+#, and so on);
  • "-geometry" attributes the resolution;
  • "-depth" stands for the color depth.

To back up my previous statement I’ve run "netstat -ta." Here is its output:

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address           Foreign Address         State

tcp        0      0 *:5801                  *:*                     LISTEN

tcp        0      0 *:5901                  *:*                     LISTEN

tcp        0      0 *:6001                  *:*                     LISTEN

Obviously, you’re going to have more connections. I’ve deleted the rest to reduce the size of the table that I’ve attached. Currently, those are the ones we care about.

That should be all you need to do on your server. Both SSHd and VNCserver should be running by now. Now, I’m going to lead you through the steps that you need to follow to be able to view your server from a remote computer (which also runs Linux).

{mospagebreak title=Setting up the Environment} 

We now need to set up the $VNC_VIA_CMD environment variable. VNC Viewers have an option called "-via" that allows use of a gateway between the server and client. If there is a gateway located, the environment VNC_VIA_CMD variable must be configured prior to viewing. In our case that variable defines the SSH options so that we’ll be able to connect to our VNC server remotely through a gateway (that is your SSHd).

Therefore, we need to run the following instruction to configure the variable:

export VNC_VIA_CMD=’/usr/bin/ssh -2 -c aes128-cbc -x -p port_number -l user_name -f -L %L:%H:%R %G sleep 20′

Notes:

  • "-2" tells the system to use SSH2;
  • "-c" manually sets up a specific encryption type — in our case it’s going to be ‘aes128-cbc‘ as that is one of the most preferable, because it is strong and fast;
  • "-p" specifies the port number — this is optional, use it only if the port of your SSHd is not the default 22;
  • "-l" specifies the username to connect on — this is optional again, use it only if your username on the server (remote) is different from the one that you currently have logged onto your client system; the rest of additional commands are must-haves, and explained in the vncviewer man-page.

Also, the previously mentioned VNC_VIA_CMD must be executed every time prior to using the ‘vncviewer.‘ But you can add this command into your ‘.bash_profile’ file. Use a text editor (e.g., nano, emacs, vim) and add two new lines containing the following:

VNC_VIA_CMD=’/usr/bin/ssh -2 -c aes128-cbc -x -p port_number -l user_name -f -L %L:%H:%R %G sleep 20′

export VNC_VIA_CMD            

Using the above technique makes sure that the VNC_VIA_CMD environment variable gets ‘exported’ on every boot (just as you’d type in manually).

If no errors occurred until now then everything should be up and running… of course, assuming that your firewall configurations are all right, and that you have SSHd configured. You could try locally to view your VNC server by executing the command:

vncviewer localhost:1

On the other hand, from another system (also running on Linux) you should be able to connect to your VNC server. Type in the following commands to do this:

vncviewer -encodings tight -via XXX.XXX.XXX.XXX localhost:1

Notes:

  • "XXX.XXX.XXX.XXX" is your server’s IP address;
  • ":1" is your display #ID;
  • "-via" command forces the system to use the "$VNC_VIA_CMD" environment variable;
  • "-encodings" command uses the specific encoding type (in our case it is called tight.)  Using specific "-encodings" is optional but recommended on low speed connections. They are truly beneficial.

Additional commands: You might add "-quality 1" and "-depth 8" to reduce color depth for the viewer (faster response, better compression). Quality 1 is the second highest because the best is 0. Other color depth examples might be 16, 32.

 That’s all!  You should be able to remotely view your server with ease —  if your client computer is running Linux too. If not, then all you need is an SSH client for Windows (or Mac, depending what OS runs on your client). As I’ve already recommended in the first half of this series, PuTTY is one of the best freeware SSH clients. Download it from here.  Run it, and at the ‘Host Name‘ (IP address where to connect) type in the external IP address of your Linux Server.

Also, don’t forget to add tunnel/’port forward’ to the port 5901 (in our case). You can do this by setting it up as source port: "5901" and destination "127.0.0.1:5901". Keep in mind that if you’re going to need more than one instance of VNC then you will forward more ports; each port must be tunneled separately. Add the display number to your ports; in the example above it was 5901=5900+1 (display number is #1, that’s why). Check out the illustrative screen shot below.

Once PuTTY is successfully connected to your SSHd all you need to do is fire up VNC Viewer and connect to "127.0.0.1," because PuTTY will forward the specified connection. The aforementioned procedure is explained in detail in the first part of this series. Anyway, I’m reinforcing again the idea behind SSH tunneling, in a nutshell.

You are connecting from your remote client to your Linux server’s SSH daemon, but after that you also need to connect to your VNC server that also runs on your Linux server, thus you need to tunnel the port 590x (x stands for the display number) to the same computer (assuming that SSHd is on same system as the  VNC server) and port 590x. Your VNC Server can be contacted on port 590x but you’re connecting to your SSH port, so you need to forward/tunnel to that port. That’s how it gets in contact with your VNC Server. That’s the main idea behind SSH tunneling and that’s why we should not forget about adding a tunnel when connecting with PuTTY.

For reference and more information head over to the first half of this series on ASP Free, called "Secure Desktop Sharing with VNC on Windows." More exactly you’ll want to check out the next to last page and examine the illustration diagram and the descriptions below it.

{mospagebreak title=More Useful VNC Commands}

One might ask how can we close and stop the vncserver service if it’s running. You can kill it using the following command:

vncserver -kill :#                       //where # is the display no.

Also, another useful tip is that you can set up your vncserver to start automatically every time your Linux system boots up. One of the ways to do this is by adding a new line to your "/etc/rc.d/rc.local." This shouldn’t surprise you if you’re familiar with Linux. A quick example would be adding the following line:

su – user_name -c "cd /home/user_name && vncserver :1 -geometry 1024×768 -depth 16"

In the above command you need to replace "user_name" with the specific user on which you want to run your VNC Server. The command "su" basically runs the command in "" (quotation marks) at the specified username-when executing more than one command, you need to separate each of them with &&. In our case, it changes the current directory to /home/user_name and executes the "vncserver :1 -geometry 1024×768 -depth 16" command.

We shouldn’t forget about the "vncpasswd" command that allows us to change the password for our VNC Server.

{mospagebreak title=Final Words}

We’ve come to the end of this article, therefore the end of the series too. I think that my two-part series should be useful and helpful. It should help you to realize many possibilities for securing connections. Encryption and SSH work wonders.

It might happen that some parts of this two part series were too hard and advanced but I certainly hope you could follow my instructions and understand what’s happening behind the scenes. That way you can benefit from SSH tunneling for many other connections. Furthermore, you should be able to configure, optimize and secure all of your connections.

If you are facing some serious dilemmas or issues don’t hesitate to contact us over at DevHardware Forums. It is definitely worth mentioning that we have a strong base of experienced members who are friendly and knowledgeable. Your question might be Linux or Windows related, SSH tunneling or even hardware, router or firewall configuration; you name it, we’re there to help you.

Good luck and I really hope that my two-part series has boosted your level of understanding, shown you new ideas and opportunities.

Now that you know how to set up, configure, optimize and secure platform independent VNC connections, it should make you feel and act confidently like a real network and/or system administrator. You will be amazed at how many times you will find yourself benefiting from VNC connections, securing other users’ connections, and feeling safe knowing that your connections can’t be easily intercepted anymore.

Be safe!

[gp-comments width="770" linklove="off" ]

chat