A client of mine recently came to me needing a way of accessing his company’s “central office” computer remotely. “Well, that’s quite a coincidence,” I said, and proceeded to tell him about PC Takeout (which, at $0, is definitely the right price). However, I could tell that he was interested in something a bit more permanent and responsive – having to go through a web browser to access the computer was far from ideal.
I was up for the challenge. After all, part of the reason that I based PC Takeout on VNC and SSH was because they were such commonly used protocols. Surely there had to be a nice, simple, standalone (at least for Windows) way of working with them.
Setting up the office computer was simple – I just downloaded the PC Takeout Installer, installed it, and set up the router in the office to forward port 22 to the desired computer. Finally, I set up a DynDNS account for the client and installed the free DynDNS Updater as a service so the host could be easily looked up (he wasn’t sure if he had a static IP or not, so better safe than sorry). A test confirmed that I could SSH in to the computer from the Internet at large.
(Side note: if you’re using the PC Takeout Installer for your own purposes and wondering what usernames/passwords to use, here’s a quick reference: the SSH user is pctakeout, the SSH password is set during the installation process, and the VNC password is “pctakeou”)
Next came the setup of the remote computer (from hereon out referred to as the “satellite” computer). At first, I thought of just using the “standalone” version of the Java client that PC Takeout uses. However, that has a few issues, one of which is the fact that the certificate is expired, and it also isn’t nearly as responsive as a native Windows application. I decided to go with the native TightVNC client, since PC Takeout uses the development version of the TightVNC server. This would let the client use the fancy file transfer stuff if they so desired.
With that figured out, it now came time to handle the SSH tunneling. I’ve used Plink in batch scripts to handle secure SQL updates – however, I’ve run into issues with the process dying unexpectedly, and it’s a pain to deal with all the possibilities in a simple batch/CMD script. I figured something along the lines of Plink was the way to go, though.
Somehow, a Google search turned up a Windows utility called MyEntunnel, a “background SSH tunnel daemon,” as its website describes it. Exactly what I was looking for! And another positive thing – it’s freeware! The author even encourages redistribution.
Setting up MyEntunnel was a piece of cake. When you first run it, you get a fairly straightforward settings screen. Fill in the username (pctakeout), enable compression (uses slightly more CPU, but could potentially help the overall speed), and set it to connect at startup if you like. Next step: set up the tunnels.
This is pretty simple. I just added the line “5999:localhost:5000” to the Local pane. This means that any attempts to connect to port 5999 on the local machine would be redirected to port 5900 on the “localhost” machine from the perspective of the central office computer. 5900 is the default port that VNC server listens on in Windows. I decided to use the local port 5999 instead of 5900, in case the client ever ended up running a VNC server on the satellite computer.
Clicking on the “Connect” key starts the magic of MyEntunnel. It will prompt for a password if you haven’t entered one already. It uses a system tray icon to convey the status of the connection – a green lock means a successful connection has been made.
Once the connection was made, it was then just a matter of configuring the VNC client. To connect to the forwarded port, I entered “localhost:99” as the VNC server (if you enter a number after the colon, that number gets added to 5900 to determine the port number to try). Since this was over an Internet connection, I chose the “low bandwidth” connection speed.
Testing it out – success! Only I found that input seemed pretty jerky, and screen updates seemed quite delayed. I traced this to the polling mode of the VNC server – the default settings in PC Takeout’s VNC server are set to poll the active window only. Changing this to full screen polling solved the issues with delayed screen updates (I’ll probably change this for future PC Takeout Installer releases).
All in all, things worked very nicely, and the client is very happy. Score one for PC Takeout!