Remote Maintenance Setup for Linux machines

The "computer guy" in the family often takes on some unofficial sysadmin duties. To make those easier the first step is to convince them to get rid of Windows and install Linux instead. That alone takes care of most of the work, however once you are there you might want to add remote maintenance. Here is a simple setup using ssh and dyndns.

First you need to sign up for an account with dyndns (which is free). You need to pick a name for the machine you want to administer remotely - let's call it falcon for this example setup. Also let's assume that this is the machine of your brother Norman, who uses the login norman.

They let you pick a domain name from the drop-down list, for the example we chose falcon.homedns.org.

The way dyndns works, is if you connect to the internet and get assigned a new IP number (the typical setup for home users) you need to sign in to dyndns and update the IP number. Each time someone tries to reach falcon.homedns.org they will get the IP number which was enter into dyndns' database the last time it was updated. This works very quickly - as soon as you update the number in their database, a ping to falcon.homedns.org will go to the new IP address.

This would be awkward if it had to be done manually and luckily it doesn't. Most routers provide a feature which does that automatically each time they connect to the internet. If that's not the case there are also shell scripts which can handle the task.

Ok, so now we have a way to reach ping falcon's router. We want to connect via ssh, so we need to open the ssh port (that's port 22) on the router and map it to port 22 on falcon. That again needs to be done in the router's setup. (Since falcon's home network looks like a single machine to the internet, you need to tell the router to which PC the incoming ssh request should be directed.)

So now falcon needs to have a ssh demon running so you can connect to it from the internet - normally you just need to check in your distribution's package tool that sshd is installed. (Also you may want to install x11vnc at this point - more on that later.)

With this setup we can securely tunnel into falcon from our home machine. Assuming we have a login and a password and also the administrator password that allows to look under the hood, maybe install a package or something like that. However for trouble shooting it's often convenient to see the user's desktop.

Since falcon is your brother Norman's machine we need to login to his account like that:

ssh -L 5900:localhost:5900 norman@falcon.homedns.org

This way we login with ssh on falcon as the user norman and at the same time redirect the VNC server port of falcon to our local machine.

To see what our brother Norman sees on his screen we need to see the X-Server display 0 - we can do that with the program x11vnc. On falcon type the following:

x11vnc -display :0 &

Now on your own machine you can start a vncviewer like this:

vncviewer :0

(For vncviewer it looks like it's connecting to the local machine, since ssh has redirected the VNC port of falcon to your local PC.)

Now you'll get a window which shows you exactly what's on Norman's screen, and you can move his mouse, type etc. He can see what you are doing on his desktop (which is great for teaching) and you can see what problem he has.

If Norman's upstream connection to the internet is relatively slow you can fiddle with the settings of vncviewer or use e.g. krdc instead on chose the "low quality" setting.

This works really smoothly for me.


Words of caution:

This gives you complete control of Norman's machine, you can even turn on the webcam and see what is happening in front of the machine. You need to make Norman aware of that, he needs to be able to decide if he wants to entrust you with so much control.

Furthermore, while SSH is a secure protocol it allows anyone to connect to the machine if they have the right password to Norman's user account - the password better be good! Also since we are using this in combination with dyndns, we are opening ourselves up to a man-in-the-middle attack. Make sure that the password for dyndns is also a good one, but this is not complete protection. Ideally only let Norman open the SSH port on the router when you actually need it.

To summarize:

• Inform the user of the security implications
  
• Set a good password for the user account
• Set a good password for dyndns
• Keep bugfixes installed, especially sshd must be up to date
• Only keep SSH port open as long as you need it