Using Remote X11 Clients

In the separable client-server architecture of X11, applications can be run on a central host and have their output and input redirected to a remote host, as is common in clustered computing environments or college campuses. Using a remote client can be useful, for example, if there's a collaborative graphical application hosted on a high-powered server and you need to be able to control it from a workstation that may not be powerful enough to run it. Another example of where this setup is useful is if the central application is very expensive and only licensed for one installation, but you need to be able to access it from any X11-capable client computer on campus; X11 makes this system possible and transparent, not to mention cost-effective. In a way, this remote use is similar to simply using SSH to log in to a remote system and then run a text-based application. The application is actually running on the server; the output and input are just being sent to your system. X11 extends this concept to graphical applications as well as text-based applications. However, this capability is disabled by default and needs to be enabled before it can be used.

The confusing aspect of using remote clients is that the terms client and server are reversed when dealing with X11. In networking terminology, you think of a "client" as being a host that runs applications located on another system known as a "server." In X11, however, the server is running on the local system, and the client is located on a remote system. Basically, a client in X11 is any program that runs under the X11 system. To make things even more confusing, your X Server may be running a client located on a remote system, which is actually a server. For example, you might load a graphical database administration client located on a remote system onto your X Server. In this case, your client is located on a remote system, but the remote system is a database server.

In order for any of this to work, the system on which you want to display the output of and control the input of the remote X11 application must be running an X Server. However, the X Server does not have to be on the same type of system. The X Server can be running on another FreeBSD system, a Linux system, a Solaris system, or a Mac OS X system. The system doesn't even have to be a UNIX-based system. There are X Servers available for Windows that can display remote X applications running on FreeBSD. Right now, the large majority of them are commercial, but an X server package for Windows, Cygwin/X, is available at http://x.cygwin.com/, and so you should be able to take part freely in the distributed X experience even from a Windows machine.

By default, your X Server will not allow remote applications to be displayed on your screen. There are a few common ways to allow this. The most common, but also the least secure, is by using xhost.

Using xhost to Allow Remote Applications to Be Displayed

xhost will allow remote applications running on a different system to be displayed locally on your system and take their input from your system. To see the current xhost configuration settings, type xhost with no arguments. Here is what the default xhost configuration will return:

# xhost access control enabled, only authorized clients can connect

In this case, only applications being run on remote systems that appear in this system's authorization list will be allowed to be displayed on this system. Also, the list is currently empty, meaning that no clients are currently authorized to send their display to this system.

If you want to be able to run remote applications on the host named lion, you need to add it to the authorization list. To do this, you use the following command:

# xhost +lion lion being added to access control list

If you type xhost now without any arguments, the system responds with this:

access control enabled, only authorized clients can connect INET:lion.example.com

The remote host lionwhich, in the context of our earlier examples, might be a mainframe in a lab across campus running a super-expensive CAD or rendering applicationcan now display its X11 applications on your local system.

The problem with this setup is that anyone who has an account on lion can send the display of its applications to your system, whether you want them to or not. This can be a major security problem in an environment with untrusted users. It's therefore not a good idea to use xhost in these environments; other methods are available that are more secure. These are discussed briefly later in this chapter.

Also, if you do use xhost, it is probably a good idea to authorize a host only just before you need it and then remove the authorization as soon as you are done working with the remote application. To revoke authorization from a host, you can use a command like the following:

# xhost -lion lion being removed from access control list

The remote host lion can no longer display applications on this system.

There is also a way to completely disable access control in xhost so that any clients can connect to the system at will. This is probably never a good idea because it is a serious security hazard. But if for some reason you want to do it, you can use the following command:

# xhost + access control disabled, clients can connect from any host

To enable access control again, type xhost -. The system responds with this:

access control enabled, only authorized clients can connect

Caution

Because of the security hazards involved with xhost, at a minimum you will want to have a firewall configured that blocks unauthorized users from outside the internal network from accessing the ports that xhost uses. xhost uses ports 6000 through 6063. See the "Enabling and Configuring the Firewall" section of Chapter 30, "Network Security," for more information on configuring a firewall.

After you have configured the system to allow a remote application to display on it, you need to connect to the remote system and start the application. You can do this through Telnet, SSH, or rlogin (though be aware that Telnet and rlogin, being unencrypted communication methods, expose you to terrible security risks).

Tip

If you are connecting to the remote system by using an X Server running on Windows, make sure you use the Telnet or SSH application included with your X Server software. Because the Windows Telnet application knows nothing about the X Server, it does not work correctly for the procedures described in the following sections. Also, as mentioned earlier, it's unencrypted and thus a grave security risk.

Starting a Remote Application

To start an application on the remote host and have it display its output on the local system, you need to set the DISPLAY environment variable on the remote host to your local system. You can do this from the SSH session. In your connection window to the remote host, you can usually use something like the following to start a remote application and display it on your system (this example assumes that your local host is named simba):

# DISPLAY=simba:0; export DISPLAY # xcalc &

This code is for a Bourne-style shell (that is, sh, korn, or bash). If you are using a C shell (csh or tcsh), replace the first line with the following:

# setenv DISPLAY simba:0

This code should start an xcalc on the remote host and display the output on your screen.

The DISPLAY environment variable has the following syntax:

DISPLAY=hostname:display#:screen#

Here, display# is almost always set to 0, and you can usually eliminate screen# unless you are on a system that has multiple screens attached to it.

Tip

Make sure you enter the information in the SSH window that is connected to the remote host. Entering the information on a local xterm window will not have the desired effect.

Other Client Access Controls

There are other ways to control which hosts can display applications on the local host. Some of these ways are more secure than using the xhost method described here. The other methods and their configuration are beyond the scope of this book. However, you might want to read the man page for Xsecurity to get you started. (Note that this name is case-sensitive when you try to access the man page.)