Configuring Basic X Access

X is the GUI environment that's most often used with Linux. As noted earlier, X is a network-enabled GUI environment. This means that X programs use network protocols to display their windows , menus , dialog boxes, and so on, even when they're run on a single computer. Understanding how these protocols work is vital to understanding how to configure two computers to allow remote GUI access. You must set options on both the client and the server.

Understanding the X Client/Server Relationship

Most people who aren't intimately familiar with network protocols tend to think of a server computer as being a big, powerful box that sits in a room somewhere, whereas a client computer is a much smaller and less powerful computer at which the user sits in order to interact with the server. Although this conception is technically inaccurate, it's usually not misleadingas a practical matter (not a matter of definitions), servers usually are powerful systems that handle data requests from less powerful systems at which users sit. This conception leads to confusion, however, in the case of X servers, because the arrangement is exactly the opposite of what most people expect: The user sits at the computer that runs the X server, and this computer can be quite limited in capabilities. The X client programs run on a computer that's often much more powerful than the X server computer.

To understand this peculiar twist, it's useful to think of the situation from the point of view of the client program. When a network client program engages in network interactions, it initiates a connection with a server program in order to transfer data. The server program exists to serve. Consider for comparison a word processor like WordPerfect and its interactions with an NFS server. (Technically, a Linux kernel module functions as the NFS client, but WordPerfect is the program that causes the kernel module to initiate transfers.) You as a WordPerfect user select the options to open a file on an NFS export, so WordPerfect initiates the network transfers, telling the NFS server to deliver a file. The NFS server responds to these requests, delivering a network service to the client. Now, suppose you're running WordPerfect remotely, from a computer in another room, via an X server. WordPerfect functions as a client for the X protocols. When WordPerfect opens a file selector dialog box, it does so by requesting that the X server display a dialog box, text, and so on. To WordPerfect, the X server is just another input/output resource, like an NFS server. The fact that the ultimate destination of the data is a human being is irrelevant to the program. This relationship is illustrated in Figure 14.1.

Figure 14.1. An X server provides an interface between the user and a program that may run on another computer.

An X server provides a GUI display device and one or more input devices (typically, a keyboard and mouse). The X server may itself be a client for other servers, such as font servers (described in Chapter 15, Providing Consistent Fonts with Font Servers). A font server delivers fonts to the X server upon request, allowing many X servers to provide a consistent set of typefaces for users.

NOTE

The overall VNC client/server relationship is opposite to that of X, but VNC includes its own special X server. The upcoming section, "Understanding the VNC Client/Server Relationship," covers the details. The fact that these relationships are reversed means that one protocol may work when another fails when a firewall sits between the client and the server. Specifically, the firewall must allow through packets targeted at the server. Thus, a firewall designed to protect computers that are generally considered client computers may need special configuration if these computers run X servers. With VNC, no such special configuration is required. SSH can also be used to twist the X client/server relationship, but in a more subtle way, as described in the upcoming section, "Tunneling X Connections Through SSH."

When you install Linux on a computer, most distributions allow you to configure an X server. This server can be used to provide local computers with access to the display. Referring to Figure 14.1, such a configuration makes the X client and X server computers one and the same. For instance, Figure 14.1's X server system might have its own X programs that it runs. The X server on a Linux system can also be used to interface with X clients running on other systems, though. Doing so requires issuing a few commands, as described shortly. If both X and other network protocols function normally on a system, it already has all the software it needs to function as an X server, so you need not install any special packages.

X client computers (those that host the programs you want to run remotely) need no special software; the X programs you want to run are the clients. To be sure, these clients almost invariably require various GUI libraries, like Qt or GTK+. With systems based on RPM or Debian packages, though, you'll be told if you need to install such libraries when you install the client program itself. In theory, you don't need to install an X server on this system, although in practice it's often simplest to do so, because dependencies between packages end up requiring you to install most of X. Technically, the X server itself is a single program that interfaces to the screen, mouse, keyboard, and so on. You may be able to omit this server, but it's often convenient to have it installed to test X-based programs locally. To make use of the X server program, you must have X client programs, either locally or on another computer.

X Servers for Various OSs

X server packages are available for OSs other than Linux and UNIX. If you want to use a Windows, OS/2, MacOS, or some other system as a GUI access terminal, you can do so by installing an appropriate X server on the OS in question. Options include XFree86 (http://xfree86.cygwin.com for Windows, http://ais.gmd.de/~veit/os2/xf86os2.html for OS/2, or http://mrcla.com/XonX/ for MacOS X), MI/X for Windows and MacOS Classic (http://www.microimages.com/freestuf/mix/), Exceed for Windows (http://www.hcl.com/products/nc/exceed/), Xmanager for Windows (http://www.netsarang.com/products/xmanager.html), and Xtools for MacOS X (http://www.tenon.com/products/xtools/). This list is far from complete, though, particularly for Windows; there are many X servers available that can be used to access a Linux system. MicroImages maintains a comparison chart at http://www.microimages.com/mix/prices.htm.

As noted earlier, there are also dedicated hardware devices, known as X terminals, that support X, TCP/IP networking, and very little else. These devices function as dedicated X servers. Companies such as Network Computing Devices (NCD; http://www.ncd.com) and Hewlett Packard (http://www.hp.com) sell X terminals. These devices often require that a computer on your network run a Trivial File Transfer Protocol (TFTP) server so that they can obtain critical boot files. (The TFTP server computer need not be the same as the computers you intend to use from the X terminal, though.) X terminals usually require that the system you intend to run use a GUI login server, as described in the upcoming section, "Configuring a Login Server to Accept Connections." You can configure even an old computer to function as a dedicated X terminal by installing a minimal Linux system and altering the configuration files so that the system uses a GUI login server to log into another system.

Configuring an X Server to Accept X Client Access

An X server, like other types of server, must respond to connections initiated by clients. Most Linux distributions, however, are designed with the premise that the system will be used as a workstation or a server for other protocols, not as an X terminal. Therefore, to use a Linux system as an X server for anything but programs run locally, you must reconfigure the system to accept X connections from other systems. There are two main ways to do this: You can use xhost on the X server, or xauth on both the X server and the X client.

Using xhost

One way to grant access to an X server is to use the xhost program to allow specific remote computers to access your X display. In an xterm or similar command-prompt window, you can type a command resembling the following:

 $  xhost +biggie.threeroomco.com  

This command instructs the X server to accept connections from biggie.threeroomco.com for your display. Consequently, any user on that computer can connect to your X server to display windows, accept keyboard and mouse input, and so on. If you omit the hostname (typing just xhost + ), your X server will accept connections from any source.

NOTE

Most X servers for Windows, MacOS, and other non-UNIX systems are configured by default to accept X connections from anywhere , much like xhost + does in Linux.

Using xhost to open your X server to connections from other systems is simple and convenient, and may be acceptable in a low-security environment. It has its problems, though. Most importantly, it doesn't provide you with any way to restrict access to specific users of a remote system. If you want to run programs that are stored on a system that has many users, a shady character on that remote system might be able to display windows and pull other pranks , or even read your keystrokes, if you use xhost in this way to open your system. For this reason, another method exists: xauth .

Using xauth

The idea behind xauth is to provide a more-or-less transparent authentication system for X connections. This utility is used transparently by the X login protocols described shortly in "Using a Remote X Login Server," but you can use it manually when connecting in some other way, as well. Although it's a bit more tedious to set up xauth than to use xhost , it's far better from a security point of view, because your X server is much more selective about the clients from which it accepts connections.

The xauth system relies on a file called .Xauthority in each user's home directory. This file must be present on both the X server and the client system, although if it's not present on one system or another, the xauth tool will create it. Unlike most Linux configuration files, .Xauthority isn't a text-mode file; you manipulate it with the xauth tool. Using xauth , you can add, delete, or otherwise manipulate X connection keys. Certain methods of starting X, such as the GUI login servers described later, check .Xauthority and, if necessary, generate a new key for the server in this file. The X server then accepts connections from any client that possesses this key. (Because .Xauthority is stored in an individual user's home directory, this key generation occurs when a user logs in or the user starts X, whichever occurs later. Different users can have different .Xauthority files.) To allow an X client to use an X server, you must copy the key from the user's .Xauthority file on the server to the user's .Xauthority file on the client. Client applications automatically try to use the key when they try to use the X server. There are several different ways to transfer an authorization key. One such procedure is as follows (a quicker one appears after this):

1. On the X server computer, type xauth to start the utility as the user who will be using the system for remote access. Note that although xauth is, in some sense, an X utility, it doesn't rely on X to operate ; it runs in text mode.

2. Type list . This displays a series of keys in the .Xauthority file. Each key begins with a display name , which is a computer hostname followed by a display number, such as term .threeroomco.com:0 . Some machine names may be followed by /unix , and you may see entries for localhost , both of which you can ignore. If some entries end in numbers higher than 0, those refer to second, third, or subsequent X server sessions run simultaneously with the first. You want to locate the display name for your main display, which will probably be your computer's hostname followed by :0 . After this name on the line will be an encoding type (probably MIT-MAGIC-COOKIE-1 ) and a 32-byte hexadecimal number. You can ignore these items, although ultimately they're what you'll be transferring.

3. Type extract xfer-auth displayname , where xfer-auth is any convenient filename and displayname is your X display name, as identified in Step 2. For instance, you might type extract xfer-auth term. threeroomco.com:0 . This step copies the .Xauthority entry for your display to a file that you can transfer to the X client system.

4. Type exit to quit from xauth .

5. Copy the xfer-auth file generated in Step 3 to the X client system (the computer that hosts the programs you want to run from a distance). You can use any method you like to do this, such as FTP, scp , an NFS mount, a floppy disk, or so on.

6. Log onto the X client system.

7. Type xauth to start this utility on the client system.

8. Type merge xfer-auth , where xfer-auth is the name of the file you generated in Step 3 and transferred to this computer. (Include the path to this file, if necessary.)

9. Type list . This action should generate a list of the authorizations on this system, including the one you've just merged. If you don't see the X server you want to add, something went wrong in the process, so review the preceding steps.

10. Type exit to exit from the program and save the changes. (Note that xauth also supports a command called quit , but this abandons the changes, so don't use it unless you've made a mistake.)

If your systems both have SSH installed, you can use the following command, typed on the X server system, in place of this ten-step procedure:

 #  xauth list  xserver  :0  sed -e 's/^/add /'  ssh  xclient  -x xauth  

This procedure compresses the preceding ten steps into a single long command, using xauth in command line mode, sed to add the command add to the start of the output, and SSH's ability to run programs remotely to execute xauth on the X client system. You should note the following features of this command:

• Type the name of the computer at which you're sitting as xserver , and the client whose programs you want to run as xclient .

• Be sure there's a space after add and before the following slash ( / ). This is a command that's passed to xauth on the X client system, and a space must separate the add command from the display name that the first xauth call extracts .

• You'll be prompted for a password or pass phrase, unless your SSH configuration circumvents this requirement, as described in Chapter 13, Maintaining Remote Login Servers.

At this point, your X server should accept connections from the X client system, although you may still need to set an option on the client system to connect to the X server, as described in the next section, "Setting Client Options to Use an X Server." When the X client program makes the connection, it will check its local .Xauthority file for the key associated with the X server.

Because the xauth system relies on keys that are, ideally , known only to the X server and its authorized clients, it's more secure than is the xhost system, at least in some respects. If you use xauth , for instance, the server will only accept connections from specific users on a client that are authorized to use the display. The X server using this system is also less susceptible to IP spoofing attacks. On the downside, the keys used by xauth are sent in an unencrypted form, so if your local network isn't secure, or if you use this method over the Internet, these keys are vulnerable to interception, thus allowing anybody with access to the key to connect to your X server. Ultimately, if highly secure X connections are desirable, SSH is a superior connection method, as described in the upcoming section, "Tunneling X Connections Through SSH."

NOTE

Not all X servers are configured to use xauth . This feature normally is active for X servers started through XDM, GDM, or KDM, as described in the upcoming section, "Using a Remote X Login Server." If you start your X server through startx , though, it may or may not be present, depending upon your X version and distribution. In some cases, you may need to edit the startx script (usually in /usr/X11R6/bin ) so that it calls xinit with the -auth authority-file option, where authority-file is the authority file (normally .Xauthority in your home directory). This step usually isn't necessary, though.

Setting Client Options to Use an X Server

Whether you use xhost or xauth to control access to the X server, you must configure the client to use the correct server. If you sit down at term.threeroomco.com and log in to biggie.threeroomco.com , and if that system tries to use wrongone.threeroomco.com as an X display, you won't be able to use the display. In fact, many Linux systems default to using their own X servers, even when you log in remotely.

When an X program starts, it checks the value of the DISPLAY environment variable to determine what X server to use. You can check the value of this variable yourself with the following command, which you type on the X client system:

 $  echo $DISPLAY  biggie.threeroomco.com:0.0 

If the output ( biggie.threeroomco.com:0.0 in this example) is your X server, then you need do nothing. (The first display is usually numbered or 0.0 , and these two values are equivalent.) If the output shows your X client or some other system, or if there is no output (indicating the DISPLAY environment variable isn't set), then you must set it, thus:

 $  export DISPLAY=term.threeroomco.com:0  

You should use your own X server's hostname, of course. Subsequent attempts to run X programs will use the server you specify. In order for these attempts to succeed, though, you need to have configured the X server to accept connections from your X client by running xhost on the server or transferring an xauth record to the client, as described earlier.

Tunneling X Connections Through SSH

The preceding discussion relates to initiating an X connection using two distinct and independent protocols. First, you connect from the X server computer using a text-mode remote login client, such as a Telnet client. Second, you use this text-mode connection to initiate a link in the opposite direction for X clients. After performing basic setup tasks , you might type xclock in your Telnet program to start the xclock program, for instance. This configuration is adequate for many purposes, but it's not without its problems. For one thing, all the data transferred over the X connection is unencrypted, and so is vulnerable to interception by third parties. The fact that each side must run a server is also a drawback in some situations, because firewalls or Network Address Translation (NAT)/IP masquerading routers may require special configuration to allow this procedure to work. One possible solution to both of these problems is to use the Secure Shell (SSH) protocol, as described in Chapter 13, to both make the initial connection from the X server system to the X client system and to tunnel X data back from the X client to the X server.

Chapter 13 describes the basics of SSH configuration and use. There are specific configuration options you need to set for SSH tunneling of X protocols to work, though:

• In /etc/ssh/ssh_config on the SSH client system (the X server system), set ForwardX11 to yes . This option enables the SSH client to accept the X data from the SSH server. Alternatively, you can launch ssh with the -X option. (Note that this is an uppercase -X ; a lowercase -x disables X11 forwarding.)

• In /etc/ssh/sshd_config on the SSH server system (the X client system), set X11Forwarding to yes . This option tells the SSH server to intercept local X calls and forward them on to the SSH client.

X forwarding by SSH works by having the SSH server run what is essentially a stand-in for a local X server. When properly configured, SSH sets the DISPLAY environment variable so that X programs send data to a particular local X server port (X server 10 by default, or TCP port 6010). The SSH server then connects to this port. Rather than display data locally, SSH encrypts the data and passes it to the SSH client. This client then makes requests of its own local X server (as determined by the SSH client machine's DISPLAY environment variable), and passes any results back to the SSH server, which delivers these results to the ultimate X client program. Essentially, the SSH server pretends to be an X server, and the SSH client pretends to be the originating X client program.

This procedure has certain advantages. For one thing, the fact that there need be only one network connection between the two computers simplifies network configuration. If you want to use an X server behind a firewall or NAT router, you may find it easier to do so if you use SSH than if you use Telnet or some other remote login protocol. Second, because SSH supports encryption, passing X data through SSH can greatly enhance security. Passwords and other sensitive data are not likely to be useable even if data packets are intercepted. The drawback derives from this encryption: Encryption requires computation, so using SSH to tunnel X connections consumes CPU time on both computers, thus slowing X displays. On CPUs of more than about 200MHz, these effects may be noticeable, but probably won't be objectionable when security is important. In some cases, the -C option to ssh , which enables compression, can improve matters by reducing bandwidth requirements. On the other hand, the compression adds further to the CPU load, which can make matters worse . You'll have to try it both ways and decide which is better on your hardware and network.

These instructions assume that you're using Linux or UNIX systems on both sides of the connection. If you're using Windows, MacOS, OS/2, or some other system as the X server, it's possible that the SSH client software won't support tunneling X connections. Even if it does support this option, you may need to determine how to activate this feature in a configuration dialog box. Consult your SSH client's documentation for more details.

A Summary of Remote-Login X Access

The preceding discussion illustrates several steps and options available to you in establishing an X connection by working off a text-mode login. There are so many possibilities, though, that it's easy to get lost. To summarize, then, a prototypical connection involves steps like the following:

1. Start the X server Your X server might run automatically if you use a Linux system and it's configured to boot into an X login screen; or you might need to run it by typing startx . On a Windows, MacOS, or other system running an X server, you'll need to run the X server program manually or configure the system to start it automatically.

2. Configure the X server to accept connections You must tell the X server to accept remote connections. This may be done by using xhost on the X server or by transferring its xauth key to the client system. This step isn't necessary if you use SSH to tunnel connections, although in that case, you must configure both the SSH client and server to perform the tunneling.

3. Connect to the X client computer You can use any text-mode remote-access protocol, such Telnet or SSH, to connect to the computer on which you want to run programs. Note that the remote computer runs a text-mode remote-access server, but it functions as an X client.

4. Configure the X client to use the correct X server X client programs use the DISPLAY environment variable to determine what computer to use for X displays. Some systems set this environment variable correctly automatically, but on others you must adjust it with a command like export DISPLAY= term.threeroomco.com:0 .

5. Run X programs You can run X programs by typing their names in your original remote-login program window. If you launch an xterm or similar program, you can use it to launch further programs.

Some of these steps, such as 2 and 4, may not be necessary depending upon the methods you use to connect and authenticate. Also, some X servers for Windows and MacOS automate some of these steps. For instance, some X servers include minimal automated Telnet or other remote-access tools that can log in using the appropriate protocol, and that then launch an xterm. Thus, once configured with your username and password, these X servers can start a connection at the click of a button, with the result being an xterm window. Consult your X server's documentation for details.

The procedures described here result in the remote system's programs being displayed on the X server computer's desktop, or sometimes in a separate window that the X server opens to host the client's desktop. (This option is particularly common on MacOS and Windows X servers.) Typically, the local system runs a window manager, although that's not always true, particularly of MacOS and Windows X servers. (X supports running the window manager from either computer.) Likewise, the desktop environment is normally run locally. If you want to maintain a minimal system locally and run the window manager and desktop environment on the remote system, you can adjust the local and remote X startup scripts to disable these features on the X server computer and enable them on the remote system. Another approach is to use a remote X login server, which typically shifts more of the burden for maintaining window managers and desktop environments to the remote system.