Linux in a Windows World/Remote Login Tools/Running GUI Programs Remotely

From WikiContent

< Linux in a Windows World | Remote Login Tools
Revision as of 21:46, 11 March 2008 by Docbook2Wiki (Talk)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search
Linux in a Windows World

Text-mode logins, as described in Chapter 10, can be handy tools for using or administering a Linux system remotely; however, they're rather limited. Many programs—particularly user-friendly tools to perform common tasks such as word processing—require the use of a graphical user interface (GUI). Such tools can't be used via a text-mode login alone, although as this chapter describes, using such a tool can be part of an overall remote GUI access plan. If you want to run GUI word processors, web browsers, graphics editors, and other programs remotely, you must use remote GUI access tools. These tools are most important as user access tools because most users today expect GUI environments. They can help provide relatively seamless access to multiple systems from a single keyboard and screen, or they can be part of a thin client configuration, as described in Chapter 12. Remote GUI access can also be used for system administration, either to run GUI administration frontends or to run text-mode programs in xterm or similar windows. (In the latter case, though, a simpler solution is usually to access the system via a text-mode login protocol.)

The features, requirements, and potential uses of GUI login tools are somewhat different from those of text-mode login tools, so these factors require some explanation, and this chapter begins with this topic. This chapter then moves on to the traditional Linux remote access tool, the X Window System (or X for short), which Linux also uses to manage its local GUI display. Next up is information on a popular alternative, Virtual Network Computing (VNC), which can be used to access either Linux or Windows systems remotely.


What Can GUI Logins Do?

GUI logins can be used for the same broad classes of purposes as text-mode logins, as described in Chapter 10—to run user programs remotely or to administer the computer. Because GUI logins are, well, GUI, you can run a wider range of programs using them than you can with a text-mode program. This includes GUI word processors, graphics editors, web browsers, and more. Programs that work best when they can display arbitrary fonts and graphics will work best with (or even require) GUI login tools. Because Windows programs are more likely to require GUI access than are Linux programs, GUI login tools are particularly important if you want to run Windows remotely.

GUI login tools' advantages come at a price, though: increased network bandwidth consumption, which translates into lower speed. You can use a text-mode login tool quite comfortably over a dialup link or an overloaded local network, but a GUI tool used in the same environment might be painfully slow. Details do differ, though, depending on the tool and the programs you use.

Several GUI access protocols are available today. In the Linux world, X and the Remote Frame Buffer protocol (most commonly implemented by VNC) are the most popular remote-access tools, and these are the two tools that are described in this chapter. An interesting variant is the NoMachine ( NX Server and NX Client. The NX Server is built around X, while the NX client can connect to other systems using the NX, X, or RFB protocols, as well as protocols that are more common in the Windows world.


Remote X access involves a lot of back-and-forth transfers, but X delivers some types of data using few bytes. VNC, by contrast, requires more bandwidth but fewer transactions. Thus, X is likely to perform best on low-latency connections, whereas VNC performs best on high-bandwidth connections. Tunneling, encryption, compression, and other options can influence both protocols' performance, though. If speed is a problem, you may need to experiment with both protocols.

Both X and VNC are a bit odd as network protocols go, but in different ways. X reverses the usual client/server relationship, as described in the next section. VNC is frequently run as a user process rather than as a conventional all-users server, as described in Section 11.4.2. Both oddities have implications for how you use the protocols. At their simplest, they require users to log in using a text-mode protocol before a direct GUI connection can be made. Ways to eliminate this requirement exist for both protocols, but these require extra configuration, which can be intimidating to those unfamiliar with the tasks at hand.

Unfortunately, neither X nor VNC encrypts data by default, so both protocols, by themselves, are risky ways to access a computer. (VNC does encrypt initial password exchanges, though.) One common solution to this problem is to use the SSH protocol to tunnel the GUI protocol—that is, to use an SSH connection as a carrier for the GUI connection, thus encrypting the GUI traffic. Alternatively, you can use a full-fledged virtual private network (VPN) to encrypt traffic. Precisely how to handle such encryption schemes is different for X and VNC, though.

Using Remote X Access

X is Linux's native GUI system, but unlike the Windows or Mac OS GUIs, X was designed with network access in mind; user programs communicate with the X server using network protocols, even when the computer isn't connected to a network. This feature makes remote X access easy—at least, in theory. In practice, you must still select an X server (if you're using a non-Linux/Unix system to access your Linux computer) and know enough about X to initiate the connection. In fact, several methods of initiating that connection exist, and some require special configuration. Most notably, you may want to configure a remote X login server, which is separate from the X server itself, to accept logins. Finally, using X in a Windows/Linux environment presents its own unique challenges.

The X Client/Server Model

One unusual detail about using X is the way the client and server roles are assigned. Many people think of servers as powerful computers (or the programs they run) that sit in machine rooms away from users, and clients as being computers (or the programs they run) at which individual users sit. Although this description is often true, it's not actually a definition of what makes a client a client or a server a server; rather, clients initiate network transfers and servers respond to those requests. In the case of X, the client is the computer or program that does data processing (a word processor, for instance), and the server is the computer or program that provides human input/output for the client. In other words, X reverses the usual configuration; users sit at X server computers and use them to run programs on X client computers. To make sense of this arrangement, think of it from the application program's point of view. To an X-based word processor, the keyboard and screen are just I/O devices, like a network file share or a network printer. The application program initiates contact with the keyboard and screen (via the X server) in order to do its work. The fact that a human sits at the X server computer is unimportant.


Because application programs are the X clients, X can't, by itself, be used as a tool for accessing Windows systems remotely. Most Windows programs aren't written as X clients but instead use calls to the Windows GUI environment. Some exceptions to this rule do exist, but they're mostly ports of Unix programs to Windows. Overall, X is a useful tool for running Unix or Linux programs from another computer, which can run Unix, Linux, Mac OS, Windows, or various other operating systems.

When using a single Linux computer, this unusual relationship seldom causes a problem; after all, the client and server computers in this case are one and the same. In network arrangements, though, the odd relationship can become confusing. For instance, to use a Linux computer from a Windows computer, you must obtain an X server for Windows. More importantly, the fact that the client (on the remote computer) initiates the connection with the server (on the user's local computer) complicates matters. Specifically, the user on the server computer needs a way to signal the client program to begin running and to contact the X server. You can accomplish this task several ways; for example, you can use a remote text-mode login tool or a protocol designed specifically for this purpose. These options are described later in this chapter.

The reversal of client/server roles can have implications on your overall network design. Specifically, many networks use firewalls or Network Address Translation (NAT) tools to isolate desktop systems from the outside world. Users of such systems can often use Telnet, SSH, or other text-mode protocols to reach outside servers, but these tools may need to be reconfigured to permit incoming connections to the X servers running on users' desktop computers. Precisely how to accomplish this task varies greatly from one firewall or router to another, so you'll have to consult its documentation (or your network administrator) for advice. X servers typically run on TCP/IP port 6000, though, so that's the one you'll have to unblock or forward appropriately.

X Server Options

If you want to use Linux as an X server for another Linux or Unix system, you'll probably use the standard X server that ships with your Linux distribution. Until 2004, this server was almost always XFree86 (, which as I write is at Version 4.4.0. The release of this version of the server also saw some subtle changes in the server's license, and many open source advocates became alarmed because they believed the changes would make distribution of XFree86 in typical Linux distributions difficult. For this reason, 2004 saw a mad rush of Linux distributions to locate another X server, and the easy winner in this contest has been's X11 ( Its first real release, numbered 6.7.0, is a fork of the XFree86 3.3.99 code (the last version released under a license that Linux distribution maintainers found acceptable).

XFree86 and aren't the only X servers for Linux. Xi Graphics' commercial Accelerated-X ( is also available. For the most part, there's little reason to use this server; however, you might find that it supports an exotic feature not supported by XFree86 or, or you might have a video card for which Accelerated-X provides superior support. Thus, if you have unusual needs or if your distribution's X server just doesn't seem to work very well, you might want to investigate Accelerated-X.

A trickier decision involves locating an X server for Windows. Quite a few exist, ranging from open source products to extremely expensive commercial offerings. A company that produces one of the lower-cost X servers maintains a list of options at but without direct links to its competitors. Here are some highlights:

This package, although primarily intended for Unix-like systems, has been ported to Windows. Check for details. This package, like many ports of Unix-like tools to Windows, is associated with the Cygwin project. One of XFree86's big advantages is that it's free.
MicroImage's MI/X ( are the lowest-cost of the commercial X servers, at $25 per user, or less for site licenses. This server used to be quite spartan, but it's improved substantially over the past few versions.
Netsarang's Xmanager ( is a bit pricier than MI/X, but at $69 for a single-user license, it's still fairly inexpensive. In my experience, it works well with most Linux software.
X-Win32 and X-Win64
Starnet produces a server called X-Win32 (, which sells for $225 in single-user quantities. A 64-bit version for 64-bit versions of Windows is also available, but at a higher price ($325). This server works well, in my experience.
Hummingbird's Exceed ( is marketed for large enterprises; I've seen it used in universities and other large installations. No single-user price is available on the company's web site.

Generally speaking, as you move up the price scale, the number of features provided by the X server software also goes up. For instance, X-Win32 provides OpenGL support, which is missing from many lower-cost packages. XFree86 is an exception to this rule; it provides features comparable to or better than those of many of the lower-priced commercial X servers. In any event, if you plan to deploy Windows X servers widely or in any critical roles, you should probably evaluate at least two or three of them. Many publishers make evaluation versions of their X servers available at no cost, typically with a time-limited license, so you should be able to test several without making a huge monetary investment.

Initiating a Connection from a Text-Mode Login

As noted earlier, one of the challenges in using X is initiating the initial connection between the X client and the X server. One approach for doing this is to use a text-mode login protocol, such as Telnet or SSH, to initiate a connection from the user's desktop computer to a remote system, then use that text-mode connection to launch X programs. For instance, suppose you're sitting at the computer called earth and you want to run programs on pluto. If both systems run Linux or Unix, you can do so as follows:

  1. Start an X server on earth. One may already be running, but if not, and if the X server is properly configured, typing startx from a text-mode login should accomplish this task.
  2. Open an xterm or other command-prompt window on earth.
  3. Configure the earth's X server to accept connections from pluto. You can do this by typing xhost +pluto. This command tells the local X server to accept all connections from pluto.
  4. Using Telnet, SSH, or some other remote-access protocol, log into pluto. For instance, you might type ssh pluto. Answer any login prompts you receive.
  5. Using your remote login session, set the DISPLAY environment variable to point to your X server. This variable includes both the hostname and the X session number, which is the same as the X server's TCP/IP port number minus 6000—that is, it's usually 0. If you use bash, type export DISPLAY=earth:0.
  6. Run X programs by typing their names; for instance, type kmail to launch the KMail program.
  7. When you're done using remote programs, shut them all down and, in an xterm window that's not linked to pluto, type 'xhost -pluto. This command removes plutos right to access your local X server, reducing the odds that another user of pluto can wreak havoc with your display.

This procedure works well but is a bit tedious. You can take some steps to simplify matters, such as creating a script with a simple name or a command shell alias to simplify typing the awkward xhost commands and setting the DISPLAY variable. If you use SSH for the text-mode connection, you may also be able to simplify things by omitting Steps 3 and 5, and the xhost command in step 7. This process is described in more detail later, in Section 11.3.


Do not set the DISPLAY variable in a startup script unless you always use the computer from the same X server. The DISPLAY variable is used even if you're accessing Linux locally, so setting it in a script that always executes may make it impossible for you to use X locally.

Windows X Server Concerns

The preceding procedure will work with Windows X servers; however, most of these servers have few or no access restrictions by default. Therefore, there's no need to type the xhost commands in Steps 3 and 7. Many Windows X servers also provide ways to combine several steps automatically, which enables you to click a link to log into a remote server and launch a program you specify (such as an xterm) automatically. For instance, Figure 11-1 shows the dialog box Xmanager displays when you launch it via its Xstart program. Enter the relevant login information, including the command you want to run, and click Run. Xmanager then executes a series of steps that have an effect similar to those described earlier. The default command for Xmanager is to launch an xterm window, using the -display option to have the xterm window, and all the programs you launch from it, run on your Windows X server.

Figure 11-1. Windows X servers provide a way to log in to a remote system and start an X session

Windows X servers provide a way to log in to a remote system and start an X session

X servers can run in one of two basic modes: rooted or rootless. A rooted X server displays everything in its own window, as illustrated by Figure 11-2, which shows a rooted display on a Linux system running the XFce desktop environment with an xterm window and the KDE Control Panel running. This approach is useful if you want to run an entire Linux desktop environment remotely but don't want that environment to take over your local computer's desktop.

Figure 11-2. A rooted X server display contains an entire Linux desktop environment

A rooted X server display contains an entire Linux desktop environment

A rootless X server displays individual windows from remote applications side-by-side with local windows, as illustrated by Figure 11-3, which shows the same Linux and Windows programs as in Figure 11-2, with the exception of the XFce desktop environment programs. This approach may be easier to manage because you can place local and remote windows more flexibly. Note, for instance, that the KDE Control Panel is sized more comfortably in the rooted display, and local and remote programs can be layered any way you like. On the other hand, a rootless display requires you to launch programs via an xterm window or some other tool that doesn't take over the whole screen, because your Linux desktop environment can't run without interfering with your Windows desktop. Many Windows X servers let you choose to run in rooted or rootless mode, so check your documentation to learn how to select the one you want. Sometimes the programs use other terms, such as single window for rooted and multiple window for rootless displays.

Figure 11-3. A rootless display lets you freely intermix Linux and Windows programs but makes it awkward to run a Linux desktop environment

A rootless display lets you freely intermix Linux and Windows programs but makes it awkward to run a Linux desktop environment

If you use a rooted X server, you'll have to start a window manager or desktop environment as soon as you log in. You can start GNOME or KDE by typing startgnome or startkde in your initial xterm window. Slimmer window managers, such as IceWM or Blackbox, can also be started by typing their names. In fact, you might be able to launch your preferred window manager or desktop environment by providing its name to your X server's startup tool. Remember, however, to also set the DISPLAY environment variable or pass options to the desktop environment or window manager to have it access the correct display! (Consult your preferred environment's documentation to learn how to do this.)

Simplifying Remote X Logins with XDMCP

One way to simplify the remote X login process is to use a program that implements the X Display Manager Control Protocol (XDMCP). This protocol is essentially a way for an X server to initiate a login connection with a remote computer, enabling an X server user to launch programs on a remote system. Three XDMCP programs are common in Linux: the original X Display Manager (XDM), the KDE Display Manager (KDM), and the GNOME Display Manager (GDM). Of these, XDM provides the fewest features, but all should work for remote logins.

XDMCP basics

One peculiarity of XDMCP is that it's used by default for local X logins as well as remote logins. All major Linux distributions run an XDMCP program whenever they're configured to boot directly into X. The default configuration, though, is to block external access requests. Thus, your task in configuring an XDMCP server is to figure out which one your system uses and reconfigure it to accept remote access, rather than install, configure, and start an entirely new server. (Of course, you can change which server you use by default, if you don't like your standard one.)

Tracking down the XDMCP server your distribution uses can be tricky. One way to start is to type ps ax | grep [xkg]dm after you've configured your system to boot into a GUI login mode. This command should return information on running xdm, kdm, or gdm processes, which will help you locate the correct configuration files.

Most Linux distributions start the XDMCP server when configured to run in a particular runlevel—typically runlevel 5. Thus, you can tell the system whether to run this server by changing your runlevel, as in telinit 5. A few distributions, such as Debian and Gentoo, don't use the runlevel to set the XDMCP server's running status; they use a SysV startup script that's active (or not active) in all runlevels, at least by default. You can locate this script and use normal SysV script handling tools to enable or disable your XDMCP server.

You also need to tell your system which XDMCP server to run. Unfortunately, there's no standardization on this point, although most distributions use a variable that's set in a configuration file. For instance, Red Hat, Fedora, and Mandrake use the /etc/sysconfig/desktop file; Gentoo uses /etc/rc.conf; and SuSE uses the /etc/sysconfig/displaymanager file. In all these cases, you can change the default XDMCP server by setting the DISPLAYMANAGER variable. Depending on the distribution, you may need to set this variable to the name of the XDMCP server, as in KDM, or to the associated desktop environment name, as in KDE. Most distributions work with either notation; be sure to read any applicable comments in the configuration files.

Some distributions use another approach to setting the XDMCP server: they call the server directly in a startup script. Debian uses the /etc/X11/default-display-manager file, and Slackware uses /etc/rc.d/rc.4. In Debian, this file contains the complete path to your preferred XDMCP server program. The default Slackware script checks for the presence of several XDMCP servers in sequence and launches the first one it finds. To change the server your system launches, you must change the order of these checks or uninstall the servers you don't want to use.

Configuring XDM

XDM is the oldest and least feature-laden of the common XDMCP servers. It provides a simple login prompt for a username and password, with no other user-accessible options. Because most desktop users expect to be able to easily shut down their computers, most distributions have moved away from XDM to KDM or GDM, both of which provide options to display buttons to shut down or restart a computer as part of the XDMCP login display. Nonetheless, XDM configuration is important because KDM borrows some XDM configuration file features.

The primary XDM configuration file is /etc/X11/xdm/xdm-config. Most lines in this file set options you shouldn't need to adjust. To configure an XDM server to accept remote accesses, though, look for a line like the following, which is usually near the end of the file:

DisplayManager.requestPort:  0

This line tells XDM not to listen on a regular port. The result is that your local X server can use the XDM server for login authentication, but remote systems can't. To enable remote servers to connect to the XDM server, either change the port number from 0 to 177, which is the default XDMCP port, or comment the line out entirely, which has the same effect.

This isn't the only change you need to make, though. You must also tell XDM what types of services it's to offer. To do this, you need to edit another file: /etc/X11/xdm/Xaccess. This file controls what clients can use the server and in what ways. A typical configuration should have lines like this:


The default configurations often have these lines, but they're likely to be commented out by hash marks (#) at the start of the line, and they may be separated by intervening comment lines explaining their purpose. In brief, the first line tells the system to accept logins from any computer, and the second line tells the system to provide a list of available local computers to any computer that asks for one. To improve security, you can specify computers or groups of computers rather than use asterisks (*) on these lines. For instance, the following configuration restricts access to computers in the domain:


Finally, recall that the XDMCP server provides local login access by default. In fact, launching this server typically forces X to start, and this is how most distributions start X: they start the XDMCP server. What if you want to provide remote X login service but not run X locally, though? You can do this by editing the /etc/X11/xdm/Xservers file, which typically contains a line like this:

:0 local /usr/X11R6/bin/X -nolisten tcp -br vt7

Details vary from one system to another, but the line is almost certain to begin with :0 local. Whatever the precise form of this line, you can comment it out by placing a hash mark at the start of the line. This action forces XDM to accept remote accesses without starting X whenever it starts.


The -nolisten tcp option causes X to not accept connections from other systems. This configuration improves security for a desktop system that shouldn't be accessed remotely, but it's detrimental for systems that should be remotely accessible. If you want to leave X running by default but enable remote logins, you should ensure that this option is not present in your /etc/X11/xdm/Xservers file.

Once you've made your changes, you have to restart the XDM server to implement your changes. Precisely how you do this varies from one distribution to another, but typically, you can change to a text-only runlevel and then back to your GUI login runlevel. For instance, typing telinit 3; telinit 5 accomplishes the job on many distributions. Some distributions, such as Debian and Gentoo, use the SysV startup scripts to shut down the XDM server and then restart it.

Configuring KDM

KDM's configuration is modeled after that of XDM, so if you want to configure KDM, you should begin by reading the previous section on XDM configuration. Most KDM installations, however, change the names and locations of some configuration files. In particular, many use kde-config rather than xdm-config. KDE configuration files may also reside in odd places, such as /opt/kde3/bin or /usr/bin. The Xaccess and Xservers files may also reside in an out-of-the-way place, such as /opt/kde3/share/config/kdm or /etc/kde/kdm.


You can use your distribution's package management tools to help locate the KDM configuration files. For instance, on an RPM system, you can type 'whereis kdm to locate the kdm binary, then use rpms -qlf option set rpm -qlf /opt/kde3/bin/kdm | grep Xaccess to query the location of that file and find the Xaccess file, making the necessary change to the path to kdm on your system, of course.

To support KDM's additional features compared to XDM, extra configuration files are required. The most important of these is kdmrc, which is likely to be stored in the same location as the Xaccess file. Use your package management system or the find or locate command if you can't find it. This file is broken into sections with labels in square brackets, such as [Xdmcp]. It's this section you may need to edit; look for the Enable and Port lines. These tell the system whether to enable externally accessible XDMCP functions and on what port to offer them. In effect, these lines duplicate the purpose of the line in xdm-config for XDM. (For safety, make changes to both files.) You should edit these lines so that they look like this:


Once you've reconfigured KDM in this way, you must restart it, much as you'd restart XDM if you were using it.

Configuring GDM

GDM uses its own unique configuration file, gdm.conf, which usually appears in /etc/X11/gdm. This file is similar in format to KDM's kdmrc, but GDM doesn't use the XDM-style configuration files, so you can ignore the XDM configuration information presented earlier; gdm.conf handles everything. To enable GDM to accept remote logins, activate its server features in its [xmdcp] section, much as you do in KDM's kdmrc:


These lines may be separated by other lines containing comments and even other configuration options. If you want to use GDM for remote logins only and not have it start a local X server, locate the [servers] section, which should have a line such as:


This line tells GDM to manage the first X display. If you comment out this option by placing a hash mark at the start of the line, GDM won't start an X server when it's run.

Unfortunately, GDM doesn't provide an easy way to restrict access to the server akin to XDM's Xaccess file; it's open either to everybody or to nobody. For this reason, GDM is best used only on well-secured local networks. If you want to use GDM on a system that's exposed to the Internet at large, you may want to use a firewall to block access to the server's UDP port 177 from unauthorized systems.

GDM provides a GUI configuration tool that enables you to set many of its options, including enabling XDMCP. To use this tool, type gdmsetup in an xterm or similar command prompt window or select the GDM configuration tool (often called Login Screen) from your desktop environment's menu system. The result should resemble Figure 11-4. The XDMCP tab contains the options for XDMCP. Be sure the Enable XDMCP box is checked.

Figure 11-4. GDM provides a GUI setup utility that helps you configure a GDM server

GDM provides a GUI setup utility that helps you configure a GDM server

Configuring an XDMCP client

XDMCP server configuration is, naturally, only half the story. Once your XDMCP server is running, you must configure a client. These clients are actually X servers. The X server contacts the XDMCP client to start an X session. When it's successful, the remote system then sets its DISPLAY environment variable and runs its X login scripts. The result is typically an X session running on your local computer.

Precisely how you configure an XDMCP client depends on the X server. Windows X servers typically provide a configuration utility that lets you point the X server to an XDMCP server. For instance, Figure 11-5 shows the Xconfig program for Xmanager.

Figure 11-5. Windows X servers typically provide ways to perform XDMCP queries on startup

Windows X servers typically provide ways to perform XDMCP queries on startup

The XDM Connection tab in Xconfig provides the means to handle XDMCP queries. In addition to the option not to use XDMCP, three modes of operation are typically available:

This option connects directly to a single XDMCP server, which you must specify. If you use an X server to connect to a single system, this can be a good option.
An XDM broadcast should locate all the appropriately configured XDMCP servers on your local network. You can also usually add off-network systems (by clicking "Register Hosts to Search..." in Figure 11-5), in which case your X server queries them, as well. The result, when you launch your X server, is an XDMCP chooser display similar to the one shown in Figure 11-6. You pick one of the systems, and click Connect to log in to it.
An indirect use of XDMCP works much like a broadcast, but the task of performing the broadcast is handed off to a remote XDMCP server. This feature can be handy if you want to access a remote network; rather than enter each potential hostname or IP address in a broadcast list, you enter a single remote XDMCP server name in the indirect field and let it do the work.

Figure 11-6. An XDMCP chooser enables you to pick which system to use

An XDMCP chooser enables you to pick which system to use

You can use a Linux system and its X server as a GUI terminal for another computer. To do so, however, you must pass options to the X program when you start it. These options are -query, -broadcast, and -indirect, to perform queries, broadcasts, or indirect broadcasts, respectively. For instance, with X not running, the following command performs an indirect connection, presenting a list of available systems:

$ /usr/X11R6/bin/X -indirect

One notable difference between Linux and Windows X servers is that Linux X servers (XFree86 and don't present a chooser if you perform a broadcast query; instead, Linux X servers connect directly to the first XDMCP server that responds. This feature makes indirect connections more desirable under Linux, at least most of the time.


Chapter 12 describes how to use old computers running Linux as dedicated X servers for more powerful Linux systems. This approach can be a useful way to squeeze extra life out of elderly computers.

Because an XDMCP-mediated login runs the user's normal startup scripts, it usually starts a full desktop environment. This desktop environment is likely to overlay a Windows desktop if a Windows X server is configured to use a rootless configuration. Alternatively, you can alter the X login scripts to provide an option to not start a full desktop environment.

Encrypting X by SSH Tunneling

One of the big drawbacks to X is that it provides no way to encrypt your data. Thus, raw X sessions are risky choices for performing tasks with sensitive data, including system administration tasks. One way around this problem is to tunnel the X connection through SSH. Fortunately, this task is fairly easy to do, and it provides an excellent level of encryption. It does require specific configuration options on both the client and the server, however.

Advantages and Disadvantages of X SSH Tunneling

By and large, SSH tunneling is a great boon for using X. Its main advantage is its encryption, but it has other pluses, as well:

SSH supports data compression as well as encryption. Using these features can improve the speed of X sessions, depending on the speed of the two computers' CPUs and their CPU loads. (See the upcoming list of drawbacks for more on this issue.) This feature is most likely to be important on slow network links.
Simplified sign-ons
The procedure for initiating the connection using the remote text-mode login protocol, described earlier, is awkward. Using SSH tunneling actually simplifies this procedure, although the underlying connection model is actually more complex.
Simplified firewall requirements
Because a tunneled X connection is carried over an SSH link, you don't need to be concerned with working around firewall limitations for X alone. If you can establish an SSH connection between a user's desktop computer and a remote server, the X connection can be tunneled through any intervening firewalls. (Firewalls on the X client and server might still remain obstacles if they're extremely tight.)

Tunneling X through SSH isn't without its drawbacks:

CPU time and speed
The encryption and decryption processes take a certain amount of CPU time on both systems. This fact can slow down connections, particularly if one or both systems has a weak CPU. This factor can sometimes be mitigated by use of SSH's compression features, which can improve data throughput, but the compression itself will consume CPU time. Ultimately, the speed consequences of using SSH tunneling are uncertain; you'll have to test it on your own network to know.
Using SSH for tunneling means that you'll need to run an SSH server on your X client computer and an SSH client on your X server system. This may complicate your software installation, particularly if you wouldn't ordinarily be installing SSH clients on your X server (that is, desktop) systems. Furthermore, not all SSH clients support tunneling X connections, although most do.
Extra configuration and debugging
Even when you'd ordinarily install the necessary SSH software for purposes other than tunneling X, you must configure both the client and server to handle the job. This task shouldn't be a difficult one, but doing it on dozens or hundreds of systems could be tedious. If something doesn't work, tracking down the source of the problem will become more tedious than it would be without SSH in the picture.
Lack of XDMCP support
Tunneling X connections over a standard text-mode login session is fairly easy, but adding XDMCP to the mix is not. If you want to provide remote system selection akin to that provided by an XDMCP chooser (Figure 11-6), your best bet is to write a simple program or to use an X server that can do the job via an integrated SSH client.

Overall, tunneling X over SSH is worth doing; these disadvantages are minor compared to the advantages, particularly in encryption. In fact, if you want to use X between computers on the Internet at large, I wouldn't recommend doing it in any way that doesn't provide encryption, and SSH is one of the simpler ways of providing encryption to X connections.

SSH Server Options

Chapter 10 provides information on configuring SSH to accept remote text-mode logins. If you've not already read that chapter and don't know how to configure SSH, you should read up on the topic. The assumption hereafter is that you have a working SSH server and can log into it from the system you intend to use as an X server.

On the SSH server computer, you should examine the /etc/ssh/sshd_config file. (Be sure to examine the correct file and not the similarly named ssh_config file, which configures the SSH client.) This file contains an option that's critical for tunneling X:

X11Forwarding yes

The default setting for this option is no, so unless you explicitly set it to yes, your SSH server will refuse to forward X connections. If this option needs to be altered, you should do so and then restart or reload your SSH server.

SSH Client Options and Use

In the Linux OpenSSH client, the /etc/ssh/ssh_config file controls the client options. This file contains an option that's analogous to the SSH server's X forwarding option:

ForwardX11 yes

This option defaults to no, which blocks X tunneling. To enable this feature by default, you must change the setting in the main SSH client configuration file. Unlike the server option, individual users can override this default with command-line options to the ssh command: the -x option disables X forwarding, and -X enables it. (Note that these options differ only in case.)

Using X forwarding is fairly straightforward: from an X session, a user can employ SSH to log in to a remote system and then immediately launch X programs, without typing extra commands:

$ ssh -X linnaeus@pluto
Last login: Mon Dec 27 11:24:49 2004 from
Have a lot of fun...
linnaeus@pluto:~> xeyes

The elaborate procedure of setting the DISPLAY environment variable and setting permissions on the local X server becomes unnecessary; more precisely, the X client and server handle these tasks transparently to the user. Programs run on the remote system are displayed on the local X server just as if a more traditional unencrypted X connection had been established. Of course, if X isn't already running locally, it must be started first.


This particular example uses the -X option, which means that it will work whether or not the local SSH client is configured to tunnel X. This option may be omitted if you've configured your local X client to do so. The remote SSH server must be configured to tunnel X in either case, though.

What about Windows, though? The procedure is basically the same for it, but configuration details may differ. In particular, you should check your preferred SSH client's configuration options for one that enables X forwarding. For instance, Figure 11-7 shows the relevant option for the PuTTY SSH client in Windows. You must check the "Enable X11 forwarding" option and, if necessary, adjust the "X display location" field (the default is fine in most cases).

Figure 11-7. Windows SSH clients typically provide a GUI menu option to enable X forwarding

Windows SSH clients typically provide a GUI menu option to enable X forwarding

Some Windows X servers include integrated SSH clients. These systems can be used to establish encrypted SSH sessions that tunnel X automatically, much as they can establish links using Telnet or other unencrypted login protocols. Thus, you may want to check your Windows X server for SSH support before using a separate SSH client.


If you're not sure whether your encryption is encrypted, one quick check is to type echo $DISPLAY in an xterm window that uses the connection. If the result reads localhost:10.0, you're almost certainly using a tunneled SSH connection. This response indicates that programs are connecting to their local computer on the tenth X port, which is the one that the SSH server sets up for its tunneling. If the result of typing this command is, and is your X server's hostname, it means that your connection isn't encrypted.

VNC Configuration and Use

X enables remote users to access a Linux system, but it's not the only tool for doing so. VNC can also function as a remote login tool, with a different set of advantages and disadvantages compared to X. One big plus of VNC is that it can provide remote access to Windows, as well, so you can log into Windows from Linux, Windows, or other OSs. Of course, configuring the server is just part of the job; you must know how to handle VNC clients. Fortunately, this task is fairly straightforward.


VNC runs a client on the computer at which the user sits and a server on the remote computer. Thus, VNC's client/server terminology is more familiar to most people than is the X terminology.

VNC Versions

One of the earliest versions of VNC was released by AT&T. That version is no longer maintained or hosted by AT&T, but it's available under the name RealVNC from Binary versions of RealVNC are available for Windows, Linux, Solaris, and HP-UX, with source code available that will compile for other Unix-like OSs. Many Linux distributions ship with RealVNC.

Another VNC variant is available under the name TightVNC , from This VNC implementation is notable because it includes some improved compression algorithms, which can improve VNC's speed. TightVNC is available in binary form for Windows and Linux, with source code for other Unix-like systems also available. Many Linux distributions ship with TightVNC in addition to or instead of RealVNC.

If your network houses more unusual operating systems (including some that aren't particularly exotic, such as Mac OS X), you may want to consult This page contains links to VNC implementations for a variety of operating systems.

One other VNC implementation deserves mention: KDE. This Linux desktop environment provides support for VNC's RFB protocol independent of a separate VNC server. This implementation is described later in this chapter.

Configuring a Linux VNC Server

VNC servers for Linux are plentiful, and some can be configured in diverse ways. Before delving into server details, though, you should understand something of how X and VNC interact because using VNC doesn't mean that you're not using X. Linux GUI programs still expect to connect to an X server, so VNC provides one. Beyond that, several options for running VNC (or other RFB server software) exist, including traditional VNC server launches, linking VNC to an XDMCP login server, and KDE's built-in tools.

X and VNC interactions

From a user's perspective, using VNC can seem simpler than at least some methods of using X for remote access; however, VNC actually complicates the internal workings of the system. Figure 11-8 illustrates the relationship between VNC and X. The VNC server is actually two servers in one: it's a server for the RFB protocol and a server for X. The X client program connects to the VNC server as if it were a local X server. The VNC server then creates a bitmap for display, much as a local X server would, but instead of sending that bitmap to a local screen, it's sent to the VNC client. This VNC client does double client duty because it's also a client for the local X server. The VNC client delivers the bitmap to the X server, which displays it on the screen. Similar interactions occur, but in the opposite direction, for delivering keypresses and mouse movements from the user to the target X program on the remote system.

Figure 11-8. On a Linux-to-Linux connection, VNC serves as a double translator between the X client and server

On a Linux-to-Linux connection, VNC serves as a double translator between the X client and server


Because Windows doesn't use a client/server model for its windowing system, Figure 11-8 is not entirely accurate when a Windows system is involved. In the case of a Windows VNC client, the VNC client delivers data to the Windows display subsystem, but it's not a client/server relationship in quite the way it is under Linux. A Windows VNC server must intercept display output using various programming tricks, rather than interface in an approved and clean way as an X server allows.

VNC was designed to provide whole-screen displays to its clients. For this reason, it delivers an entire remote desktop, much like to an X server that runs in rooted mode (as in Figure 11-2). VNC has no equivalent to X's rootless display.

VNC delivers entire bitmaps from the server to the client. By contrast, an X client can and often does deliver shorthand descriptions of operations, which the X server interprets locally. This difference means that VNC must frequently deliver more data across the network than does X, but X's transactions involve more back-and-forth exchanges. These characteristics give rise to the differing performance limitations of the two protocols, with VNC degrading on low-bandwidth networks and X degrading on high-latency networks.

Traditional user VNC server sessions

To use a regular VNC server, such as RealVNC or TightVNC, you must first install it. You may want to check your distribution's package list to see if it includes a VNC server (probably under a name like tightvnc or vnc-server). If you can't find a VNC package for your distribution, check the RealVNC and TightVNC web sites. These have source code and binaries in various formats, such as tarballs and RPMs. Note that some VNC packages split off the VNC client from the VNC server, whereas others include everything in a single package.

Once you've installed the VNC server, it's time to configure it. You must do this as an ordinary user—specifically, the one who will be using the server:

  1. Create a ~/.vnc directory in your home directory to hold VNC configuration files.
  2. Create a new VNC password by typing vncpasswd. By default, VNC doesn't use the Linux password database, so each user must set a VNC-specific password.
  3. Run the server by typing vncserver. The system should respond with a message like this:
    New 'pluto:0 (linnaeus)' desktop is pluto:0
    Creating default startup script /home/linnaeus/.vnc/xstartup
    Starting applications specified in /home/linnaeus/.vnc/xstartup
    Log file is /home/linnaeus/.vnc/nessus:6.log

At this point, the VNC server is running on VNC port 0 (indicated by the :0 trailing the machine name—pluto in the preceding example). Be sure to remember this port number because it's necessary for connecting to the VNC server! The VNC port number, like an X port number, is relative to a larger number—5900, in the case of VNC—so VNC port 0 is TCP port 5900. You should be able to connect to the server using the VNC port number in a client, as described in Section 11.4.4.

When you first start the VNC server, it creates a default startup script in ~/.vnc/xstartup. This script is equivalent to a normal X startup script; it launches applications when the VNC X server starts. The basic configuration, though, is to launch an extremely primitive window manager called twm. If you're used to another desktop environment or window manager, you should edit this file to change the reference to twm to something else, such as startkde to start KDE or icewm to launch IceWM.

The vncserver command is actually a script that calls the real VNC server program, Xvnc. If you want to make systemwide changes to VNC's defaults, you must edit the vncserver script. Ordinarily, you'll do this as root, although you can copy the script to your home directory as an ordinary user and edit it yourself, if you prefer. Options you may want to adjust include:

The new user startup script
The startup script written by vncserver is contained within it, typically identified as defaultXStartup or something similar. You can edit this script as you see fit; however, this change will affect only new VNC users, not existing ones.
The font path
Unfortunately, VNC is very sensitive to the font path—the list of directories in which it searches for fonts. This is identified by the -fp parameter to Xvnc, so if you want to change the font path, you should search for that string and make changes to any variables or Xvnc calls that specify it. The -fp parameter takes a comma-separated list of directories as its option. You may want to try using the font path specified in your /etc/X11/XF86Config or /etc/X11/xorg.conf file, although these files specify the font path in a multiline format rather than as a comma-separated list. Including empty or invalid directories on your font path is likely to cause the VNC server to crash, so if in doubt, start with a shortened font path and add entries to make it work as you like.
Virtual screen size
VNC presents a virtual screen in which it creates your Linux desktop. You can adjust the size of this virtual screen with the -geometry option to Xvnc, so look for the line in the vncserver script that sets this option. This is usually set in a variable called geometry near the start of the script.
Color depth
If you want to have VNC deliver more or fewer colors, you can set the color depth option, which is passed to Xvnc via the -geometry parameter. Most vncserver scripts set this value with the depth variable near the start of the script.

Once you as an ordinary user are finished with VNC, you can shut it down by passing the -kill :session-number option to vncserver. For instance, vncserver -kill :0 kills VNC session number 0.

Linking VNC to an XDMCP server

The usual mode of VNC's operation is peculiar by Linux server standards. Instead of connecting to the server using a fixed port and entering a username and password to gain entry, you must log in using a text-mode tool or run the server while you're at the console, then connect using a port number that you must remember and enter a password (but no username). This approach certainly works, but it can be a bit awkward if arbitrary users should have access to the VNC server. To work around this problem and create a more typical Linux-style login experience, you can tie VNC to an XDMCP server. The result is that, when users connect to the VNC server, they'll be greeted by a GUI login screen that's similar to the one they see when logging in at the console or via an XDMCP-enabled remote X server.

Before proceeding, check the earlier Section 11.2.5. You should configure your XDMCP server to accept remote connections, with one possible exception: you can use Xaccess rules or firewall rules to restrict XDMCP access to the local computer itself. Both the XDMCP server and the VNC server will be running on the same computer, and the XDMCP server only needs to accept connections from the VNC server. You can configure the XDMCP server to be more promiscuous in the connections it accepts, but if this isn't necessary, it can be a bit of a security risk, particularly if the computer is accessible to the world at large, and you use firewall rules or super server security settings to restrict access to the VNC server.

Once you've configured the XDMCP server, you should edit your /etc/services file. This file gives names to various TCP and UDP ports. You should add entries for any ports you want to assign to VNC. The names you use are arbitrary, but vnc or something related to it is a logical choice. Note that you can use just one port or many ports. Using many ports lets you run multiple VNC servers with different options—for instance, to run servers with different virtual screen resolutions for the benefit of clients with different screen resolutions. For example, suppose you intend to run VNC with 760 530 and 950 700 resolutions. First, create two entries in /etc/services:

vnc-760x530   5900/tcp
vnc-950x700   5901/tcp

This configuration assigns TCP ports 5900 and 5901 to VNC, using names that describe the intended uses for these ports as supporting different resolutions.

Once this is done, edit your super server configuration to call the Xvnc server. This call must include several parameters that are normally handled by the vncserver script, such as -geometry, -depth, and -fp. Other options that may be necessary include:

This option specifies the X session number; each unique X session needs its own session number. Note that this is an X session number, not a VNC session number. If your system normally runs a local X server, begin with :1. You can also begin with :0 if no conventional local X server ever runs on the system. Some systems work best if you omit the X session number, enabling VNC to pick one dynamically.
This option disables access controls in TightVNC—that is, the initial password request. Because XDMCP handles this task, disabling the initial VNC password request is desirable. Some VNC versions don't need or support this option, though; they use the -SecurityTypes option instead or disable access controls as a side effect of other settings necessary for this configuration.
This option is RealVNC's equivalent of TightVNC's -ac option.
Ordinarily, a VNC server runs until killed; even if you disconnect from the server, it continues to run. This option causes the server to terminate after a connection is lost. Its behavior is desirable when VNC is used with XDMCP because it better implements the traditional Linux login/logoff procedures.
This option tells Xvnc that it's running from a super server.
-query localhost
This option speaks to the VNC server's X server side; it tells the server to contact a specific computer for an XDMCP login. In this case, the server contacted is localhost, which should work well. You can use or your computer's external IP address or hostname if you prefer. (Using localhost or may result in slightly better performance, though.)

To produce a xinetd configuration incorporating these elements, create the file /etc/xinetd.d/vnc. This file should have one or more entries like this:

service vnc-760x530
   disable      = no
   socket_type  = stream
   protocol     = tcp
   wait         = no
   user         = nobody
   server       = /usr/bin/Xvnc
   server_args  = :1 -inetd -query localhost -geometry 760x530 \
                  -depth 24 -ac -once \
                  -fp /usr/share/fonts/misc/,/usr/share/fonts/100dpi/


The large number of arguments passed to Xvnc dictates splitting them across three lines in this book; however, they should all be entered on a single line in reality. Backslash characters (\) denote continued lines here but should not be entered in your real configuration files.

You may need to experiment with the -ac and -SecurityType parameters to get this to work. Your font path is also likely to be longer than the one shown here. Some distributions, such as Fedora, provide a font server for local use, which can greatly shorten the font path entry, but the entry is likely to read unix/:7100.

After restarting your super server, the VNC server should become available to VNC clients, as described in Section 11.4.4. You'll notice several differences in how VNC behaves, though:

  • Multiple users can log into a single VNC port.
  • Users don't need to explicitly configure their VNC sessions.
  • Users' VNC logins produce their standard desktop environments, as set by X system defaults and users' own options.
  • Sessions are destroyed when users log out; they must save open files or their unsaved work will be lost.
  • Users don't enter VNC passwords, but they have to enter a password at the XDMCP login prompt.
  • If you set up multiple VNC ports to accept logins with different parameters, the VNC session number controls access to the options you set. For instance, connecting to pluto:0 could yield a 760 530 display, whereas connecting to pluto:1 can produce a 950 700 display.

Overall, linking VNC to an XDMCP server can be an excellent way to provide remote GUI logins to a Linux system. This approach follows typical expectations for GUI logins and works much like accessing Linux via a rooted X server using XDMCP. VNC client software is inexpensive and easier to configure than X servers, though, which can simplify your overall configuration and education efforts, even if linking VNC with XDMCP is a bit more work.


One downside to this approach is that usernames and passwords sent to the XDMCP server are unencrypted. (Ordinary VNC passwords are encrypted, although the rest of the session data is not.) Given that most VNC data isn't encrypted, this isn't a huge difference, but it is worth noting and may make a difference in your plans, particularly if you want to use VNC across the Internet.

KDE's VNC features

KDE is unusual in that it supports the VNC protocol, RFB. You can access KDE's options from the KDE Control Center (type kcontrol in an xterm window or locate the Control Center option in the KDE menu system). The options in question are visible in the Desktop Sharing area within the Internet & Network option set, as shown in Figure 11-9. (Specific KDE implementations vary somewhat in their names for these options; for instance, some use Network rather than Internet & Network.) KDE's Desktop Sharing system works more like VNC under Windows than under Linux: it shares an existing login session, rather than create a new session. The intent is that it be used as a collaborative tool, to enable users to create demonstrations and presentations for other users at remote locations. For this reason, it emphasizes use by invitation: click Create & Manage Invitations to create a time-limited password, which you can give to another user in some appropriate way, such as over the phone. (You can also email invitations directly, but this makes them susceptible to network sniffing.)

Figure 11-9. KDE's VNC support enables you to share an existing KDE login session

KDE's VNC support enables you to share an existing KDE login session

KDE also supports "uninvited" connections, which are essentially time-unlimited invitations. This tool isn't likely to be useful for providing yourself with remote access, though, because KDE displays a dialog box on its local display whenever a connection attempt is made. If you don't accept the connection, the remote system is refused access. Thus, remotely accessing the system via KDE's VNC features requires that somebody be present at the console when a connection attempt is made.

Configuring a Windows VNC Server

One of VNC's advantages over X is that you can use VNC to remotely control a Windows computer. Windows wasn't designed with multiuser access in mind, however, so instead of running a server that creates a virtual session unrelated to anything displayed on the console screen, VNC under Windows copies what's shown on the computer's main display to the client. This is similar to the approach taken by KDE with its integrated VNC support, although some details differ. This can be a good way to control your own single-user machine when you're away from it, but it obviously won't do if two users want to share a single computer; each user's actions would battle the other's.

You can obtain VNC for Windows from the RealVNC and TightVNC web sites. This chapter uses TightVNC for Windows 1.2.9 as a reference. The program comes as a Windows self-installing archive, so you can double-click it to launch an installer, which is typical of this class of program in Windows. You'll be asked if you want to install the client, the server, or both (the default is to install both). If you install the server on a Windows NT/200x/XP system, at the end of the process, you're asked if you want to register TightVNC as a Windows service. Doing so launches TightVNC when Windows starts, so you can access it remotely before any user has logged in. This can be a handy way to provide multiple users access to the computer, but only one at a time. If you don't want to provide this sort of access, TightVNC will launch only after you explicitly run it. (You can also place a link to the TightVNC server in a user's Startup folder, in which case it runs as soon as the user logs in.)

When you first launch the VNC server, it presents the WinVNC: Current User Properties dialog box shown in Figure 11-10. This dialog box enables you to set various options, some of which are equivalent to Linux VNC options and some of which are Windows-specific. The most important of these options is to set the password for VNC access, so enter that immediately. When you've set the options you want to use, click OK to launch the server. You should notice a small VNC icon appear in the task bar on the bottom of your screen; double-click it to change your VNC server's options.

Figure 11-10. The Windows VNC server uses a GUI tool to set options that are set via command-line switches in Linux

The Windows VNC server uses a GUI tool to set options that are set via command-line switches in Linux

Using a VNC Client

VNC client operation is fairly straightforward. In Linux, you use the vncviewer program. If you type the command name alone, it presents a GUI prompt for the VNC server. Alternatively, you can pass the server name on the command line. In either case, you can include the VNC session number, as in vncviewer pluto:0. If you don't include the session number, the default is 0. This default works well for most Windows VNC servers and for the first VNC server launched on a Linux system.

Under Windows, you can launch the VNC client by selecting it from the Windows Start menu. The result is a GUI prompt for the VNC server, similar to the one the Linux VNC client presents. As with that prompt, you may need to enter a session number if the server runs more than one VNC server.

With either OS client, after you enter the server's name, the client tries to connect. If it succeeds, the client immediately prompts for a password if the session is password-protected; however, if you've configured a Linux VNC server to interface to an XDMCP server as described earlier, you'll see no VNC-specific password prompt. Instead, you'll see a Linux XDMCP login screen, as shown in Figure 11-11, which shows a Windows VNC client connected to an XDMCP-enabled Linux VNC server. You can then log in as if you were at the console. Thereafter, no matter the type of the server, you can use the system more or less as if you were sitting at the remote computer.

Figure 11-11. VNC can present a close replica of the remote computer's display, potentially including a GUI login screen

VNC can present a close replica of the remote computer's display, potentially including a GUI login screen


Some Windows configurations require you to press Ctrl-Alt-Del to log in. To do so from a Linux VNC client, press F8 to obtain a menu of special keystrokes and options. Windows VNC clients provide similar options from their windows' menus.

VNC isn't without its flaws. Here are some problems and quirks you may notice when using the server:

  • Overall system responsiveness may seem sluggish, particularly if you're using a slow or overburdened network or if your display is quite dynamic.
  • When connecting to Windows servers, parts of the display may not update in a timely fashion. This is a consequence of VNC's imperfect interfacing to the Windows display system. Linux servers tend to be better about displaying screen updates as they should appear.
  • Keyboard mapping may be imperfect, particularly when connecting to or from systems with odd keyboards. Some Macintosh keys may not map sensibly, for instance, if you connect to or from a Mac OS system.
  • Colors may appear strange. Unfortunately, VNC clients and servers don't always handle colors in a perfect manner. Changing the server's color depth can often improve matters.

Encrypting VNC Connections

VNC's lack of encryption can be a serious drawback. Fortunately, it's one that can be corrected with the help of additional software—namely, SSH. Using SSH to encrypt VNC can be more complex than using SSH to encrypt X, though. Configuration begins on the VNC server computer, which must run an SSH server in addition to the SSH server. The SSH server must be configured to accept tunneled TCP connections:

AllowTcpForwarding yes

This option, which should appear in the /etc/ssh/sshd_config file, is the default, so chances are you won't need to change it. Once it's set, SSH is configured to accept forwarded connections, and the server-side configuration is done.

The simplest way to use a tunneled connection is to employ the -via option to TightVNC's vncviewer command in Linux. This option takes the name of an SSH server that forwards the traffic to the ultimate target system. For full point-to-point encryption, this system would be the same as the VNC server:

$ vncviewer -via

The result will be a prompt for your SSH password on the remote system followed by an ordinary VNC login. Unfortunately, this approach isn't available in the Windows version of TightVNC or in either version of RealVNC. For these systems, you must set up an explicit SSH tunnel using the SSH client package on the client computer. You do this by using several options to the ssh:

$ ssh -N -f -L

This command tells the SSH client to set up a mapping from the localhost port 5902 to's port 5900, using as the system that passes on the data. (Ordinarily, you'd want to use a single hostname for both the proxy and the target system; I've specified two names here just to make it easier to identify what's doing what. Likewise for the port numbers; chances are you'd use the same one on both systems, although you might use different numbers if your local port 5900 is occupied.) Once you type this command, you're prompted for a password and then the link is established. To use this link, you can run any VNC client, but you must link to your localhost address on the VNC port specified in the ssh, minus 5900:

$ vncviewer localhost:2

When combined with the preceding ssh, this command links to's port 5900 (VNC port 0), using as the SSH proxy. This might be useful if your main concern is with snooping on intermediate systems, and you trust the security of the connection between and You can also specify the same computer as both systems, though, provided you can run both an SSH and a VNC server on that computer.

This approach works with Windows clients and servers as well, although of course some details do differ. In the case of a Windows VNC server, you need to install and configure an SSH server, as described in Chapter 10. Precisely where you'll find the option to enable TCP forwarding varies from one server to another, so consult your documentation. Likewise, Windows SSH client configuration for this task varies from one client to another. Typically, you must enter the source and destination ports in a special configuration screen, such as the one shown in Figure 11-12 for PuTTY. In PuTTY, after entering the information in the Source Port and Destination fields as shown, you click the Add button to add forwarding, then initiate an ordinary SSH session to the VNC server or the SSH server you intend to use as a proxy. Thereafter, connecting to the localhost address on the specified port with your VNC client forwards the connection.

Figure 11-12. Windows SSH clients typically enable you to enter port forwarding instructions in a special configuration menu

Windows SSH clients typically enable you to enter port forwarding instructions in a special configuration menu

Running Windows Programs from Linux

If you are willing to make a monetary investment that will enable your Linux clients to run Windows applications, there are two popular and related methods to consider. Both methods run a Windows desktop session on a server that you connect to and control from a Linux desktop running the appropriate client software. This is similar to VNC on Windows as described in the previous section, but one of the major differences is that multiple Linux desktops, possibly several hundred, can connect to a single Windows server at a time. This is a perfect setup when you want to deploy Linux desktops but still need the ability to run one or more Windows programs in their native form. Nearly all programs should run flawlessly because they really are running on a Windows computer; it's simply their display output that's shown on the Linux machine. However, processor or memory-intensive applications should not be run in this fashion because a single program consuming most of the system's resources may ruin the experience for the users.

The minimum requirement for this kind of setup is a Windows server, preferably Windows Server 2003, that has Terminal Services enabled. Windows 2000 also has this ability built-in, but Windows NT requires the special Terminal Server version. On the Linux side, you can use a program called rdesktop , which speaks Microsoft's Remote Desktop Protocol (RDP), to connect to the Windows server and run a desktop session. Just like VNC, these sessions can run at full screen or inside a program window. It is possible to cut, copy, or paste text between the remote Window desktop and the local Linux desktop, but you can't drag and drop files. Beyond the cost for a Windows server and server license, you have to purchase a Terminal Services Client Access License for each user or machine that will connect to the Windows server. The rdesktop program isn't supported by anyone other than the open source community, so if you have problems using it, Microsoft won't help you. This is one reason you might want to consider the second method.

The second most popular way to run Windows applications on Linux uses a third-party application called Citrix Metaframe that runs on top of Windows Terminal Services. This program provides additional features not found in regular Terminal Services, such as concurrent licensing, server pooling, and a native Linux client that uses Citrix's thin client protocol known as ICA. Citrix licensing fees are on top of the ones that already exist for the first solution, but if the extra features are needed, the price is easily justified.

Setting up either server is beyond the scope of this book. However, if you want a quick test to see how well this works, you can use rdesktop to connect to a Windows XP Professional computer. Microsoft includes support for one remote desktop connection in Windows XP Professional to enable administrators to make a remote GUI connection for troubleshooting purposes. In most cases, this service is already running on the computer, and you simply need to install rdesktop on your Linux client and run a command, such as: rdesktop -g 800x600 IP address (where IP address is replaced with the actual address of the Windows computer) to connect to the Windows computer.


Remote GUI logins can be a useful tool for enabling users to run complex GUI programs remotely and even for system administration. Windows benefits the most from remote GUI system administration, because text-mode Linux tools are usually sufficient. Two tools are particularly important in cross-platform remote GUI logins: X and VNC. X is Linux's native GUI tool and is a very useful way to access a Linux system from another Linux system or from a Windows system. VNC is a cross-platform tool that can enable Linux or Windows clients to access either Linux or Windows servers. (Other operating systems are also supported.) One problem with both X and VNC is that they don't encrypt data by default, with the exception of VNC passwords. One way around this limitation is to employ SSH as a tunneling protocol. This process works most easily with X, but, with a bit of effort, it can also be used with VNC.

Personal tools