Once 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
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.
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 192.168.1.10:0. 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
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 [email protected]
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 192.168.1.10
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
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.