|
Graphical Remote Control Desktops for Linux
Controlling Windows Computers From LinuxA 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.
Installation and Use of RDPThis 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:
Linux workstation VMware Server host to guestVM: 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 InstallationNXclient, 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. # 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:
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
and add this entry (substitute whatever IP address your router actually uses on the network.) 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
|