Graphical Remote Control Desktops for Linux

By: A. Lizard
Thursday, October 30, 2008 11:57:44 AM EST
URL: http://www.linuxplanet.com/linuxplanet/tutorials/6567/1/

Controlling Windows Computers From Linux

A remote control desktop is a software application that permits the monitoring and control of a computer desktop and its applications from another computer. That software will make it possible to view and run applications and configure files on the remote-controlled machine as if you were sitting in front of it, you will see the desktop on the monitor, and control it via the physical mouse and keyboard of the computer you are actually using.

You can do this interactively with a user present on the remote-controlled machine so the user can see what you are doing and you can see what the user is doing, which is handy if you are trying to teach the user something.

This series will show you how to set up remote control desktops which will make it possible for you to control a Windows box from Linux, or control your Linux box from another Linux computer. It is necessarily Debian-family specific, though what's here may well be useful as guidance even for rpm-based distro users.

Client and Server

You run a remote-control server on the computer you want to remote-control. A remote-control client accesses that server to permit you to monitor or operate it as if you were sitting at the physical machine. In the rest of this article, the "server" is the computer being remote-controlled, the "client" is the computer the remote control is directed from.

Controlling Windows computers from Linux

One of the annoying facts of life for a Linux user is that one's immediate circle of family and friends know that you are the most knowledgeable computer user they know and will frequently get volunteered to get them out of the trouble they got themselves into with their Windows environment. Having a way to remote-control their computers can save you a lot of drive time.

What is RDP?

RDP is a remote access protocol for PCs developed by MS as an addition to an ITU standard, RDP's purpose is similar to the popular Open Source VNC protocol.

Why rdp instead of the better known vnc? The rdp protocol is encrypted by default - no activation of a second program like stunnel to provide ssh is necessary. While rdp is a microsoft extension of an ITU standard, the Linux Open Source rdesktop client is available to work with it. It also works with Virtualbox. An rdp server is also built into or available for all Windows versions from Windows 2000 onward.

Installation and Use of RDP

This article is written on a Debian Lenny workstation running Sun Virtualbox 1.6.2. However, the procedure should be either identical or very similar across a wide range of Linux distros. Note that on Virtualbox and VMware Servers, it is possible to bypass the built-in remote servers in each console. This is a far more difficult setup and is more appropriate for remote server guestVM control than for an individual SOHO user running virtualization on his own desktop.

Linux workstation virtualbox host to guestVM:

  1. Open Virtualbox. Open Settings > Remote Display for the VM you want to enable. I set my XP host to 4000
  2. $ rdesktop -a 24 0.0.0.0:4000 [the IP points at the Virtualbox host] - if you can't find the virtualbox RDP server, try netstat -an and look for something with the port set for Virtualbox. (the Windows default port is 3389 - I set it for 4000 in Virtualbox -- XP -- Remote Desktop -- XRDP Server
  3. You can also use GUI Remote Desktop programs like krdc and Gnome RDP.
  4. Note: this will only work with 1 VM at a time unless you assign a different port in Settings > Remote Display - port [text entry box] per VM
  5. NO CONFIGURATION IS REQUIRED IN THE OSs RUNNING ON THE VM.
  6. It should be possible to access the RDP servers from XP/Vista from the Linux desktop directly, though in this case, the guest VM OSs will have to be configured.

Linux workstation VMware Server host to guestVM:
  1. $ rdesktop -a 24 0.0.0.0:5900
  2. Start > Internet > Remote Desktop Connection (KRDC > 0.0.0.0:5900 (will connect via the insecure by default VNC application- which will have to be installed) Note that within one's personal workstation, I don't regard insecure connections as a serious issue.
  3. I don't know if this can be run with multiple guestVMs at the same time.

Linux to remote Windows server

$ rdesktop -a 24 xxx.xxx.xxx.xxx:3389

The xxx* should be replaced by the IP of the machine you want to control. On Windows versions prior to XP, a downloadable server app will have to be downloaded, but RDP and Windows 9.x are not compatible.

I had hoped to be able to set up a Linux rdp server to make it possible to use the rdesktop client to control Linux computers. Unfortunately, no matter what your list of applications installable via repository says, there is no such thing as a usable Linux rdp server.

The problem with xrdp - the x11rdp module is missing in the binaries.
"Mar 6, 2008 ... is not compiled at all: it is not part of the source of xrdp 0.4.0. To make it work, you will have to compile yourself . ..."

Unfortunately, source build with xrdp also fails. I've seen reports that getting the latest version via subversion and building this from source works, but anyone who grabs the very latest build of a package from the developers can confidently expect trouble.

Those of you who are creating an environment intended for actual use in your business or academic life need one that normally works and doesn't need continuous debugging.

This is an example of EPIC FAIL, if it doesn't work, it should not be in distros.

So it's time to try something that does work.
This picture (Figue 2) was taken in front of my public library where I was using its wireless access point. This is my eeePC 901 showing my workstation desktop with my workstation e-mail client running in VMware Server on a Windows guestVM. I was running NX client to connect to the NX server running on my desktop. Once I had the setup done correctly on the server machine, I connected on the very first try.

NX Server (free version from commercial developer)


WARNING: Unfortunately, NX Server and Freenx are not ready for unsupported inexperienced Linux users to install. The commercial / payware version does come with support and perhaps a better installation setup, inexperienced users may be better off with it despite the extremely high price.

While this is a proprietary application, source code has been provided by NoMachines to the Linux Open Source community for their server and client applications.

Unlike vnc, this is secure by design, it's built to work automatically with the OpenSSL ssh package. You can find out more about these packages from NoMachines.

NXclient Installation

NXclient, the NX client application, seems to work with Windows 2000 / 2003 / XP / Vista, OSX, Solaris, and across a wide range of Linux distributions, it installed without trouble on even the heavily tweaked Xandros environment running on the eeePC 900. You can get NXclient for your OS here.

Since this software is provided as binaries for direct download and installation rather than via repository either via distro or by NX Server onsite custom repository (as IMO, they should be doing), dependencies are not automatically handled.

For Linux, install NX client by:

# aptitude install libstdc++2.10-glibc2.2
# aptitude install ssh

# dpkg -i nxclient*

The extensive work required to make ssh work for NX Server appears unnecessary for NX Client alone. However, to complete the setup for NX Client, a key generated by an NX Server installation is required. So install this now and forget it until later.

For other operating systems, follow the instructions on the NoMachines site. As long as the server key is provided to the NX Client running on these other OSs, they should neither know nor care what your server OS is.

If you are installing the server, forget about installing the rest of the software for a while.

You must have a 100% operational ssh / sshd setup with all applicable keys in place and correctly configured for use with NX Server running on your workstation before you install NX Server. Simply having a copy of the ssh metapackage installed on your computer is only the start of what you need to do.

Making ssh work is also the extremely hard part. Unfortunately, simply installing ssh or having it installed automatically as part of your distribution does not solve the problem, it has to be manually configured.

You'll also have to do some manual configuration of these networking files:

  1. /etc/hosts
  2. /etc/hosts.allow
  3. /etc/hosts.deny

The process is difficult and tedious enough that it should have been handled by distribution-specific custom scripts bundled with the Debian (for instance) installation in the installation files created for nx* by nomachine.

Networking setup for NX Server

/etc/hosts
There is probably an error in your hosts file.

The typical /etc/hosts in Debian-based distributions places host and alias entries in the wrong order. Replace the 127.0.0.1 loopback address localhost and machine entry names with something in this format:

127.0.0.1 localhost localhost.localdomain computername

and add this entry (substitute whatever IP address your router actually uses on the network.)

192.168.1.1 router

Don't change anything else. While the router entry probably isn't really necessary, if you have to use nmap to troubleshoot the network, it will save you trouble if nmap will provide you with information about what it thinks your router is doing.

A good command for nmap ssh troubleshooting:

$ nmap -p 54321 --open -sV 192.168.1.1/24

change the numeric IP to match your LAN router if need be and 54321=whatever port you actually set ssh to.

If you don't have nmap installed, install it:# aptitude install nmap

The DynDNS -- Open Port Tool will help you check your ports from the public Internet.

/etc/hosts.allow

These should be the only user entries in the file.

ALL: LOCAL @192.0.0.1/24
ALL: sshd


If your LAN runs a different IP range, use that in place of the numeric IP in the LOCAL entry.

/etc/hosts.deny
Remember that any unsuccessful SSH connection attempt will result in the entry for the computer you are trying to legitimately connect from added to the ";forbidden hosts" list which is what hosts.deny is, which will have frustrating results. I recommend renaming the file to /etc/hosts.deny-temp and recreating the file afterwards. (see below) If you find localhost or 127.0.0.1 or anything else you know to be a legitimate connection in this file, delete the entries. If you find any entries for off-system connections you didn't put there, that's what the file is for, leave them in.

Once you've finished, restart networking by:

# /etc/init.d/networking restart

That's all for today-- come back next Monday to learn how to set up secure Internet access even with dynamic IP addresses, and how to set up NX Server.

This security bulletin should be of interest to admins using rdesktop and other applications that use the rdp protocol:Microsoft Windows Server Service RPC Vulnerability

Copyright Jupitermedia Corp. All Rights Reserved.