Basic X Remote Logins

To understand X in a networked environment, you should first understand a peculiarity of X. Most servers, such as web servers, FTP servers, SSH servers, and so on, run on computers that are at a distance from the user who accesses them. The user sits at a computer that runs a client program. This relationship is reversed for X; individuals interact most directly with the server computer. The client may reside on the same computer (in a non-networked configuration) or on a distant system. This relationship is outlined in Figure 26.1. To understand this arrangement, think of it from the point of view of the client program. A web browser (client) uses a network protocol to exchange data with a server program. When you run a user program, such as a web browser, via a remote X connection, you become one of the remote sources of information. The program queries the X server to obtain your input (in the form of keystrokes and button presses) and delivers information to the X server (in the form of text and graphics to display). The web browser client is simultaneously a client for the Hypertext Transfer Protocol (HTTP), with which it interacts with the Web, of course.

Figure 26.1: An X server functions as a way of transferring data between a user and a user's programs.

Because clients initiate contact with servers, the arrangement just outlined means that the remote computer must initiate the contact with the local one. This configuration presents a challenge: How do you, working on the server computer, tell the client that you want to work with it? The most straightforward solution is to use a conventional text-mode login tool, such as SSH or Telnet. The full procedure involves the following steps, using bunyan.luna.edu as the local computer and blueox.luna.edu as the remote system:

1. Log into bunyan as you normally would. If necessary, start X on this system.

2. Tell bunyan that you want its X server to accept connections from blueox. If bunyan is running Linux or another Unix-like OS, you do this by typing xhost +blueox.Iuna.edu in anxterm.

3. Use your remote-access tool to log into blueox. For instance, you might type ssh blueox.luna.edu and then enter your password.

4. On blueox, type export DISPLAY=bunyan.luna.edu:0. This command tells X programs on blueox to use the first display (that is, display 0) on bunyan rather than a local display.

5. Type the name of any program you want to run. For instance, type galeon to launch the Galeon web browser.

6. When you're done, use an xterm on bunyan to typexhost -blueox.luna.edu. This command tells bunyan's X server to stop accepting data from blueox. This action is a precaution, in case a miscreant with an account on blueox wants to cause you trouble by opening windows on your system.

This procedure works in most cases, but it leaves room for improvement. Some problems with this procedure include:

Tedium Compared to a simple text-mode login, this process is tedious. It can be simplified in various ways, and in fact most of the rest of this chapter is devoted to describing methods that can be used to reduce the number of steps involved in obtaining remote access.

Security X doesn't normally encrypt any data. Even if you used SSH in Step 3, data passed via X will not be encrypted. Of course, if you use SSH to log in, your password will at least be protected, provided you don't type it again in any X windows. Step 2 tells your local system to accept X data from the remote system, regardless of who's sending it. Therefore, if the remote system is a multiuser system, and if somebody on that system wants to display bogus windows on your system or perhaps even intercept your X-based keystrokes, you have no protection. More sophisticated authentication is possible using a tool called xauth, but it's tedious to configure and isn't as secure as using SSH to tunnel the connections, as described in the upcoming section, "Tunneling X through SSH."

Non-Unix Local Machine Problems If your computer doesn't run Linux or another Unix-like OS, you may not have an X server installed on it. Numerous X servers are available for Windows, Mac OS, and other computers, but most are commercial products, some with hefty price tags. Versions of XFree86 are available for Windows

(http://www.cygwin.com/xfree/), Mac OS X

(http://www.apple.com/macosx/x11/ or http://www.mrcla.com/XonX/), and OS/2 (http://os2ports.com), among others. Low-cost commercial products such as Mi/X (http://www.microimages.com/freestuf/mix/) and Xmanager (http://www.netsarang.com/products/xmanager.html) may also be good options. Most non-Unix X servers don't require explicit authorization in Step 2. Some provide procedures to help automate the login process; for instance, they may be able to use Telnet to log in and launch an xterm window without requiring you to launch a Telnet client.

Firewall Problems The method just described requires client/server connections that run in both directions: An SSH, Telnet, or other text-mode login session running from you to the remote system and an X session running from the remote system to you. This configuration can require extra effort to pass through a firewall. The problem is particularly acute if one or both systems lie behind Network Address Translation (NAT) routers, which complicate configuration of servers on their protected networks.

Full-Screen Sessions This procedure works best to enable you to run individual programs. As presented, it probably won't work to run an entire desktop environment, because your local computer probably already runs one, or at least a window manager, and one screen won't easily support two window managers.

For all of these reasons, this procedure is best applied on a short-term basis or for occasional use. For regular, ongoing use, chances are you'll want to employ another method. Using an XDMCP server, as described in the next section, is a good choice if you want to dedicate a computer to doing little but running another computer's programs. Using SSH, as described in the upcoming section, "Tunneling X through SSH," is a good choice for security or if you need to regularly run programs from several computers. Using VNC instead of X, as described in the upcoming sections, "Basic VNC Logins" and "Linking VNC to XDMCP," is a good way to run an entire desktop environment, and it may be a superior choice when running a server on your local computer is impractical. VNC may also be less expensive or easier to configure on non-Unix systems than an X server.

0 0

Post a comment