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.