Setting up VNC in Linux Mint, tunneling over SSH and connecting remotely from Windows

As we saw in my previous post, the result of working through X11 is ok, but not very pretty (although I have a feel that there is more to it, so, if you know, please comment :) ). If you want to see your desktop from another machine, the next level up is to use Vino (VNC) but many folks warn about security risks with this, as VNC per-se does not have encryption. This also requires for you to keep a session open/logged in the Linux machine (it is basically sharing the desktop). That is not the case with Xterm. It is just one more user connecting to the server.

Anyhow here is the way (I would advice to read first the whole thing so that you get an overall picture, before starting with the details):

1. To remotely access the box from Windows. Mint comes with VNC server Vino, for full graphical access. Also, check this video.
2. To launch the server in the terminal: /usr/lib/vino/vino-server
3. To change preferences use vino-preferences in the terminal or type remote in the start menu (and desktop sharing will show up). 
4. Nevertheless, that does not set all the preferences! I was having an issue connecting with TightVNC or with RealVNC because I didn't the right encryption. Type  gsettings set org.gnome.Vino require-encryption false to disable encryption.
5. To check that the server is running and waiting: netstat -ln -A inet. To understand netstat you can check Wikipedia. Examples for Unix can be found here and here. For the DOS version, which is still cool, click here.
6. A funny one... download gvncviewer (vnc client for linux) and run it with your own machine address. It will just go in a crazy loop exporting himself... You can close it by closing the top window.

Anyhow this is all good and easy to test within our own network, without having to go through a firewall or connecting remotely to the server in a network with dynamic IP address.

Nevertheless, as mentioned, VNC does not have encryption. Also, trying to remotely connect to a machine, for instance, at home, supported by DSL where the service provider changes your IP address every now and then, is also a challenge. So, we tackle here those two problems.

For the first, to increase security, you will want to connect VNC through SSH (tunnel). Here is the way I did, but there are also this link, this and this one (that I found but didn't use). Trying to understand this better, I found this nice link. The way I understand it:

1. The trick lies on a very nice capability from SSH. Basically, we can request the SSH client to listen on a particular port on our local machine, and forward that down the secure connection to a port on a machine at the other end. I.e., step 2 and step 3 here are telling to the SSH client to:
1. Listen  to a given port (the VNC port 5900) in the local machine. When we launch VNC in the local machine, we will give it an IP address (127.0.0.1) which will be explained later, and by default, VNC tries to connect to the port 5900, so, there is where the SSH client listens to, to "catch" those attempts.
2. If there is anything, forward it to the SSH server on the other side and tell it to pass that to the right machine and the right port. In my case, the right machine is the same running SSH, and by default, I got the VNC server running on the default port (5900).
2. So, again , in those steps, the "source port" is the port on the local machine that PuTTY listens to, and the "destination" is the server address and the port where you want that information to be forwarded to.
3. Now, instead of having the VNC client (RealVNC or whatever), connect to the remote address ("destination"), we tell it to connect to our own machine VNC server (There is actually not such a thing, just that PuTTY will be listening there). This is done by entering the address 127.0.0.1, which is a standard address to indicate loopback. I.e., the packets that come and go from the computer network adapter are routed in and out at the network adapter level, back into or out of the machine, without ever touching the external network (LAN). See this. So, the VNC client doesn't even realize of the trick.
4. Notice that in the remote network, where the server is sitting, gated by a given firewall, we don't need to open the VNC port on that firewall, but just the SSH port.

For the 2nd problem, on doing a VNC to a machine in a network with changing IPs, one can read this. Basically, you got to register your domain name in some server in the Internet and then, have your network, somehow, report back its IP periodically in case it has changed. So, two things are needed here.

1. First the dynamic DNS (DDNS) server. A good list of free ones can be found here. Basically register your domain name (whatever the name you want it to be) to your network IP. The domain name may be a full name (that you may have got somewhere) or a partial name, where you pick a portion of the full domain name and the rest is assigned by you DDNS company. I am using duckdns.org, and my server domain name will be something like myname.duckdns.org.
2. Second, your network has to report back the IP periodically, to that server, so, that the server can now it has changed. This can be done by the router of the network (D-LINK is an example of that and they even provide the DDNS server for free) or, if your router can't do that, by a computer within the network, thanks to some kind of app that the DDNS company will give you. In my case, duckdns.org gives you a step by step installation for different platforms. Really easy. In my case, using Linux, my server will use crontab to periodically send the IP to the DDNS server (duckdns.org).

Note: somehow my router seems to be a branding of a D-LINK but not sure it is working, so, I am using the crontab.

Finally, now that we got all this running, it wouldn't hurt to step up the security and get some other cool stuff going. Check my lastest post on this topic...

Cheers!