Run a Business Network on LInux: Remote Help Desks

Tuesday Jul 15th 2008 by Carla Schroder

Phone support doesn't always cut it: Sometimes your help desk has to see what the end user's seeing to solve a problem.

Carla SchroderOnce upon a time, back in the very olden days, when something went wrong with one of your possessions and you couldn't fix it yourself, you had two options: have a repair person come to your house, or take the item into a repair shop. This was a good system that worked smoothly for many a millennia- big things like refrigerators and console televisions got house calls, and little things like toasters and lawn mowers went to the toaster and lawn mower hospitals. Then along came the personal computer, and overnight this pleasant, smoothly-functioning infrastructure was turned on its head, and life for computer users became nasty and brutish. All because of a sadistic new invention: the Telephone Support Center.

It costs a lot of money to maintain a useful number of repair centers, or to roll a truck to a customer's site. So deep in the bowels of high-tech land, a demented genius came up with the idea of having telephone support centers. This allowed computer vendors to consolidate their repair centers into a very few locations, and to hire battalions of "help desk" worker bees who could be housed wherever it was cheapest. Customers who were having problems with their computers would then call in to these help desks, and receive coaching over the phone on how to diagnose and fix their own computers.

Naturally this proved to be of limited effectiveness, and yet it persists to this day with a couple of minor variations: e-mail support and online chat. The result is virtually no actual diagnosis and repair, but reformat-and-reinstall as the universal solution. At the retail level we're probably stuck with this for the foreseeable future, but in the workplace there is a much better option, and that is the remote helpdesk.

Remote Helpdesk = Helping Hands

"Remote helpdesk" means you have remote control of a user's PC, and can operate it from your comfortable IT lair just as though you were sitting in front of it. So instead of trying to coach some poor user through their own PC surgery, you can take control of it and quickly figure out what's going on and set it right.

There are many excellent tools in Linux-land for remote administration: OpenSSH, VNC and its multitude of variants, and rdesktop. Any Linux workstation or laptop running a graphical desktop can be your remote control network administrator fixit machine.

Remote Graphical Desktops

Figure 1. Click for a larger image.

OpenSSH is a great secure tool. But one thing it does not let you do is attach to a running session, so you can't see what your user sees. I like VNC a lot because there are variants of VNC for all occasions: Linux-to-Linux, Linux-to-Windows, Linux-to-Mac, running multiple PCs from a single keyboard, mouse, and monitor, and many more combinations and permutations.

VNC is client-server. The computer you want to access runs the server, and your ace network administrator PC runs a client, which is also called the viewer. Both KDE and GNOME come with VNC servers, which make it easy for your users to authorize a new remote connection. KDE's VNC server is called Krfb, and GNOME's is Vino. You'll find it in your GNOME menu as Remote Desktop.

KDE's Krfb

For obvious security reasons it is a bad idea to leave wide-open invitations to remote logins running constantly on any PC, so your users will issue invitations as needed. All they have to do is open Krfb, then click Create Personal Invitation. Your user will then see a window like figure 1, which shows them the address and password to give you. Another option is Invite Via Email, which is a nice way to do it because you can copy and paste.

On your side of the network, you can fire up KDE's remote desktop client Krdc. First enter the remote address, such as The remote user will have to accept the connection. Then you'll enter the password, and you're connected and can take control of their desktop. If you're not running KDE then any VNC viewer will work fine, such as xtightvncviewer, xvncviewer, xvnc4viewer, or any of the many other VNC viewers that roam the Linux skies.

Gnome's Remote Desktop

Figure 2. Click for a larger image.

GNOME's Remote Desktop operates in a similar fashion, as Figure 2 shows. It has one major difference: it allows password-less logins. Again, any VNC viewer connects to GNOME's Remote Desktop.

Securing Linux VNC Sessions

VNC sessions run in the clear, so a good way to encrypt your sessions is by tunneling VNC through an SSH connection. You'll need OpenSSH servers already set up and running on your client computers, and you need your user's logins since you're attaching to existing sessions. Open a tunnel to the remote PC from your PC like this:

$ ssh -N -L 5900:localhost:5900 bob@bobspc

This runs in the foreground, so open a second terminal or your graphical VNC client, and connect to localhost:0. For a command-line VNC client it's usually as simple as xvncviewer localhost:0. It will behave just like an un-tunneled session, and you can verify that packets are encrypted with tcpdump or Wireshark.

Helping Windows Users with rdesktop

You can help Windows users just as easily, though it's a rather limited set of Windows users: Windows NT/2000/2003, XP Pro, and the "professional" versions of Vista. But not Starter, Home Basic, Home Basic N, or Home Premium. And they say there are too many Linuxes. At least none of them are artificially crippled.

In NT/2000/2003 you need to set up Terminal Services. On XP Pro and Vista it's called Remote Desktop Sharing. Then you can log in from Linux using rdesktop, which is an open source remote desktop protocol client. This example opens a new session and specifies the window size:

$ rdesktop -g 1024x768

Now you should see the Windows login box. This won't attach to an existing session, but open a new one. You may bump into licensing restrictions because Windows servers require client licenses for terminal servers. XP Pro allows only a single remote session at a time, and the local desktop is locked.

Helping Windows Users with TightVNC

What if you want to take control of an existing session? Then you want TightVNC and the DFMirage video driver. Install these on any version of Windows except Vista. (Sorry Vista users, here's another thing that won't work.) The DFMirage driver is a virtual video driver that gives great peppy performance to your remote Windows sessions. It's not required, so if you have to you can use just TightVNC.

When you install TightVNC you have the choice of running it as a service, or in application mode. For helpdesk work application mode might be better, since your users will presumably run it only when it's needed. There are a number of configuration options, but only one is essential- be sure to check the "Accept Socket Connections" box. The rest is all personal preferences, such as enabling a password, blocking local input, the area of the desktop to be shared, and so on. The TightVNC password is unrelated to any Windows logins, so you don't need any user account information.

Connecting to Windows is done using the IP address or hostname and port number, like this:

$ vncviewer stinkpad

The standard port number is 5900. If you set up a different port number, specify it this way:

$ vncviewer stinkpad::5901

You may also connect via an SSH tunnel for security just like in the above example. You can install OpenSSH on Windows via Cygwin, or use any SSH server than runs on Windows.


Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved