This document outlines how to VNC to a CentOS 5 or RHEL 5 box using an SSH tunnel and PuTTY as an SSH client
If VNC is not currently running and working properly on your machine, then read my previous post VNC Server Configuration for CentOS 5 and RHEL 5.
The below steps describe how to securely deploy an encrypted VNC solution for your CentOS and RHEL servers while assuming VNC is already correctly configured on your machine. Also, it is assumed that SSH is running, which is the default for every Linux implementation that I’ve participated in.
To ensure that only encrypted VNC connections are supported by your CentOS or RHEL server, the first thing that needs to occur is to edit your /etc/sysconfig/vncservers file. At the bottom of the file there is at least one line that starts with VNCSERVERARGS. One option needs to be added to each line that begins with this argument.
This option is –localhost. Below is an example configuration.
VNCSERVERARGS=”-geometry 800×600 -nolisten tcp -nohttpd -localhost“
The –localhost option will prevent any connection over VNC without a secure channel such as an SSH tunnel.
PuTTY can easily be found through a google search. Once installed on your Windows machine, set up an SSH connection to the linux server you wish to VNC into. In the below example I used 188.8.131.52 (a google IP that will not work in real life). Substitute this IP for your own.
Once this connection is created, save it and then make sure it is loaded. Your configuration should look just like the one below except for the IP.
Navigate to Connection and SSH and finally Tunnels and enter the Source port (I used 6901 to help minimize the possibility of overlapping ports). Then enter 127.0.0.1 as the Destination with the same port as the source port so that it says 127.0.0.1:6901. Use the below screenshot as an example as to how you should fill out the Tunnels configuration.
Click on the Add button and highlight the new Tunnels connection you just created. Once highlighted (it’s important that you click on the connection so that it is highlighted since this is a common mistake that causes a lot of grief), click on the Open button.
Once the session is open, log in with your username and its corresponding password just like you would for a normal SSH session. Once at the command prompt, issue the following command:
[jsmith@centos ~]$ ssh –L 6901:localhost:5901 jsmith@localhost
Enter the password (in this case, it is for jsmith) once again and make sure there are no errors reported (Note that the first port [6901 in the above example] needs to be the same as the one entered in the Tunnels section when you configured it within PuTTY). What this command is doing is taking anything coming in over the SSH tunnel on port 6901 and sending it to VNC which is listening on port 5901. Port 5901 will not change since that’s what VNC is listening on based on the configuration file found in your /etc/sysconfig/vncservers file. If you have more than one user, then the corresponding display number (:1, :2, :3, :4, etc.) must match the correct port number (5901, 5902, 5903, 5904, etc.) of the user you are logging in as.
Finally, startup your VNC viewer and enter 127.0.0.1:6901 for the server (see the below screenshot for the combined steps of 5 and 6). After you hit Connect you should be asked to enter in your VNC Server password.
It’s interesting to note the sessions that are established and the ports that are listening.
We see established connections on ports 6901 and 5901 as well as two established connections on port 22. You may notice that the IPs in the 192.168.168.0 range don’t match the original IP from step 2, but it is not uncommon to see this IP disparity. This can be explained by NATing behind a firewall or proxy. The true IP can be an RFC 1918 address while the public-facing IP is something entirely different.
We also see in the below screenshot that VNC (Xvnc with a pid of 7351) is listening on 5901 while SSH (pid 7696) is listening on port 6901 as a result of the command we issued in Step 7. SSH is also listening on port 22, which is where the seminal connection occurs. Again, all this is to be expected. If you’re having trouble establishing a tunnel using SSH for your VNC needs, take a look at your connections using the netstat command. If everything looks like the below screenshot, then most likely your iptables configuration needs a second look to make sure port 22 is open.
As mentioned in a previous post, do not set up root as a VNC user. The risk is too great. I can think of a handful of reasons not to do this (there are probably dozens) and they are all serious. Don’t allow your desire for convenience to circumvent good security practices. The whole reason you’re implementing VNC over a secure tunnel is for a more secure environment. Don’t offset your efforts by allowing root over SSH and VNC.
Sometimes VNC acts a bit temperamental. Two key commands that come in handy are:
[jsmith@centos ~]$ sudo killall Xvnc
[jsmith@centos ~]$ sudo service vncserver restart
You may need the full path of the command if your $PATH variable doesn’t include /usr/bin or /sbin.
If you are connecting from a Mac or Linux box then the concept should be similar, though I have not tested it out with any other client other than PuTTY.