Working in the support business, remote access systems is your daily bread and butter. We’ve seen remote access become increasingly easy, especially with the advent of services such as teamviewer, GoToMyPC, Crossloop, and the zillion derivatives of these programs.
There are of course the commercial alternatives, such as the well-known WebEx from Cisco, even SonicWALL has its very own "Virtual Assist" which allows technicians and experts to help end-users over a remote desktop.
But what if you cant afford these commercial systems, maybe on a shoestring budget, have a relatively small support team or similar? Maybe 9like in my case) the free services are either too slow, or you need to implement something inhouse. I recently wanted to tackle this problem and cam up with two similar solutions. My rules of engagement were:
1. Use open source / free software
2. Make sure the client to server communication is encrypted and secure
3. Make this as much as possible a one-click experience for the end user, most users are frustrated that they have to call support, having a difficult remote access system only aggrevates them more.
Ok so starting on the design phase… the main workhorse had to be something reverse-VNC based, since its open source, well known hence mature, and very easy to deploy. Second, in order to encrypt the communication easily we could use the vnc plugins, but this could add some extra complications for the user. So I went with ssh encryption. Its relatively trivial to setup an SSH tunnel to a server, and from there forward the VNC connection to a tech PC. This has the added advantage that we’ll be able to get around most firewalling without the need for NAT / port forwarding on the client’s side. This is especially true if we setup the SSH server to listen on port 443 instead of the normal 22, since almost all networks have outbound port 443 enabled for HTTPS traffic.
We roughly know what we have to build, so on to the nitty girtty. I decided to use the UltraVNC flavour of VNC since I’ve always had good experiences with this. I downloaded the full blown VNC installation and installed this on a machine. From this machine, we look for the file named "winvnc.exe" and I copied it out. When first run, winvnc will generate a file name "ultravnc.ini" which it uses as a configuration file to control subsequent connections. In order to make the "application" as one click as possible, we create the file "ultravnc.ini" and copy paste something similar to file (the original was simply copy / pasted from a working VNC server):
[Permissions]
[admin]
FileTransferEnabled=1
FTUserImpersonation=1
BlankMonitorEnabled=1
BlankInputsOnly=1
CaptureAlphaBlending=0
BlackAlphaBlending=0
DefaultScale=1
UseDSMPlugin=0
DSMPlugin=
primary=1
secondary=0
SocketConnect=1
HTTPConnect=1
XDMCPConnect=0
AutoPortSelect=1
InputsEnabled=1
LocalInputsDisabled=0
IdleTimeout=0
EnableJapInput=0
QuerySetting=2
QueryTimeout=10
QueryAccept=0
LockSetting=0
RemoveWallpaper=1
RemoveAero=1
DebugMode=0
Avilog=0
DebugLevel=0
AllowLoopback=1
LoopbackOnly=0
AllowShutdown=1
AllowProperties=1
AllowEditClients=1
FileTransferTimeout=30
KeepAliveInterval=5
DisableTrayIcon=0
MSLogonRequired=0
NewMSLogon=0
ConnectPriority=0
[ultravnc]
passwd=CBAE6D810BAEAFDFAEpasswd2=CBAE6D810BAEAFDFAE
The important parts are highlighted in bold:
– The allowloopback is especially important else the connection will fail when connecting through the SSL tunnel
– The passwd is also important to set ( I set this arbitrarily) because without it, VNC will no accept incoming connections option, which I deleted from the above sample because each customer / user will have a different path
Next, some backend work. Since this is a private remote access system we need to have the infrastructure to support it. Nothing much really, all I needed was to provision an extra Ubuntu server VM with very minimal features including:
– OpenSSH
– Apache2
– Iptables
Another piece of advice: if using a VM, take a snapshot after you’re done configuring and regularly restore the snapshot just in case it gets compromised or something. We setup the SSH server to listen on port 443 instead of the normal 22 as already discussed. The apache configuration we’ll leave for later. Setup the strict IPtables and the server is relatively ready.
On the tech PC side, there’s not much to do. Instruct them to install UltraVNC and run the VNC viewer in “Listen Mode”. They should then see the icon in their system tray with the port it’s listening on, usually 5500: 
Make sure there’s no firewall blocking or antivirus that disrupts communication. That’s it. There are some options to deply VNC to a large number of computers if you wish, just FYI
Oki so we have an SSH server that can reach the tech PCs, the tech PCs which are listening on port 5500, and the client-side VNC which is almost all provisioned. That leaves us with creating the ssh tunnel from client to server and setting up local port forwarding.
SSH port forwarding is probably one of the most useful but underutilised features of SSH clients. Bascially, once an SSH connection is made to the server, you can redirect traffic fromt he port of your choosing to go over the tunnel to some remote host on the server’s subnet. More details here.
I’ve already referred to “plink” in one of my other blog posts. Its basically PuTTy’s cli mode. The command we’ll use to setup the SSH tunnel and SSH forwarding would be:
plink -P 22 -pw password -L 127.0.0.1:65535:10.71.10.6:5500 root@10.71.254.250 –N
I guess we should explain the syntax a bit here:
-
· -pw = password
-
· -L = setup SSH port forwarding. This takes the format of [ local_ip : local_port : remote_ip : remote_port ]. So in our case the remote_ip and remote_port will be those of a Tech PC in the SSH server site.
-
· root@[server_ip] = username and IP of the SSH server to connect to. Of course don’t use root… use some user with absolutely no priviledges… don’t forget these credentials are visible to the client
-
· -N = don’t open an SSH shell… the client doesn’t need it.
Once the SSH tunnel is setup, we instruct the VNC server to connect back to the tech PC. Since SSH forwarding is setup, in the above example is the tech PC’s local IP is 10.71.10.6, then we simply tell the VNC server to reverse connect to 127.0.0.1:65535, which will redirect the VNC traffic to the IP 10.71.10.6 port 5500 over the SSH tunnel… encryption and NAT/firewall traversal, just like that! 🙂
We now need to package all this together for the client. I would use some 3-rd party install-maker or executable zip file here, but for my purposes i’m simply going to bundle plink.exe, winvnc.exe, ultravnc.ini and a batch file called “clickme.bat” into a ZIP file
“Clickme.bat” has two commands : one to start the SSH tunnel to our server, the second to start the VNC server. It’s contents:
START "My Company Support" plink -P 22 -pw SonicWALL -L 127.0.0.1:65535:10.71.10.6:5500 root@10.71.254.250 -N /B
winvnc.exe -autoreconnect -connect 127.0.0.1::65535 –run
The first command starts plink in a separate window entitled “My Company Support” and immediately moves to the next command. ( More details on the START command here)
The second command instructs winvnc.exe to connect back over the ssh tunnel and autoreconnect if it drops. (more details on the winvnc command here)
So we have a ZIP file with the components:
Winvnc.exe
Ultravnc.ini
Plink.exe
Clickme.bat
We now just have to distribute this to clients. This is where the apache server comes in. You can upload the ZIP file to the apache server and instruct clients to get the package from here.
There is quite a drawback here. Since in the plink command we must specify the IP of the tech PC (10.71.10.6 in my example), we need to build a package for each and every tech. It’s not such a major problem , considering you can use excel to generate the command, and the zip file is about 500KB, so it won’t take too much space… but you do have to keep it in mind.
The second solution which is similar to the above is to use UltraVNCSC (single-click). You can read about it here
http://www.uvnc.com/addons/singleclick.html
You basically need to upload a zip file to the website and a nice .exe file is returned. Its quite elegant but the fact that you need to upload a file to the website kills it for me. If I have 30 techs, that means 30 zip files and a lot of time uploading to the site… not my cup of tea.
How well does my method work in real life? Well… it works J The VNC connection itself does of course depend on the sort of connection you and your client have. It really is a single click experience. Clients just download, run the .bat file, and press “y” to accept the SSH key. One thing I did notice though is that it takes about 30-45 seconds to connect back to the tech PC. Still, quite good 🙂
David Vassallo's Blog 