Remote Desktop in Linux - Part 2

In Part 1, we demonstrated how easy it was to administrate a system via a remote desktop session with openSUSE, SLED and SLES. Now, lets discuss how we can secure your remote desktop session by encrypting the data stream between the remote system and your local machine.

We will use Secure Shell (aka SSH) to encrypt the VNC (RFB) protocol via a technique called SSH Tunneling. More info on the subject of tunneling protocol at Wikipedia.

Pre-conditions:
1) You have SSH running (enabled) and you have a strong password on your remote system.
2) The Firewall is set to allow SSH traffic on your remote system.

On your local machine, we create a SSH tunnel to the remote machine, via the terminal as follows:

ssh -L 5900:localhost:5900 -f -N user@remoteIP

ssh is the secure shell program and the rest are parameters. -L will forward a particular port (ie 5900) on the local machine to another port (ie 5900) on the remote machine. -f requests ssh to go to the background. -N tells ssh not to execute remote command as we are just port forwarding. user is the user on the remote system. remoteIP is the reachable Internet address of the remote machine.

A successful SSH connection will prompt you for the user's password. Enter the password and you have a secure shell tunnel.

Next, execute the typical vncviewer command as follows:

vncviewer localhost:0

Noticed we point vncviewer to the local machine. If the SSH tunnel is setup corrrectly, it will intercept the vncviewer RFB protocol and forward it to the remote machine for execution. [localhost:0 translate to localhost and port 5900]

Now, we have the VNC (RFB) protocol leaving your local machine encrypted by the SSH protocol. Upon reaching the remote machine, the VNC (RFB) protocol will be delivered to port 5900 where the vncserver is running... and vice versa.

Do expect a hit on performance as we are wrapping a protocol (RFB) within another (SSH). I do not have a good user experience as the remote desktop feels sluggish. One workaround is to reduce the size of the remote desktop from the typical 1024x768 to 600x480 (or any other dimension as long as you're still productive). Another suggestion is to use the -deferUpdate flag to set a higher time (in milliseconds), default at 40, to wait before sending all the user interaction updates down the stream.

If you find the above too painful or performance hit unacceptable, there are other Remote Desktop alternatives with encryption. One very popular Remote Desktop software is from NoMachine.com. The underlying NX protocol is Free(as in speech) and open source(GPL). The client and server software for Linux are Free(as in beer/soda).