home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam  

Unix Power ToolsUnix Power ToolsSearch this book

6.10. Starting Remote X Clients

One of the unique advantages of window systems such as X is that you can run applications remotely and view them on the local display (as opposed to systems that merely allow for the execution of shared applications by the local host, such as Windows and the Mac OS prior to OS X). Even Mac OS X, except insofar as it can run an X server, does not allow for a split between an application's display and its execution. Only X-aware applications may be executed in such a fashion.

6.10.1. Starting Remote X Clients from Interactive Logins

You can try this easily enough by doing an rlogin or telnet[33] to the remote host, setting the DISPLAY environment variable and starting up an X client. Of course, it helps to have an X server already running on your local machine. In the following example, we start up a new xload client running on the host ruby:

[33]Most of the recent distributions of Unix default to the use of ssh as a secure replacement for the various r* command, (rsh, rcp, rlogin, et al.), so you may want to skip ahead to Chapter 5.

sapphire:joan % rlogin ruby
Last login: Mon Mar 12 16:27:23 from sapphire.oreilly.com
NetBSD 1.4.2A (ORA-GENERIC) #6: Wed May 31 06:12:46 EEST 2000

TERM = (vt100) xterm

ruby:joan % setenv DISPLAY sapphire:0
ruby:joan % xload &

(You must, of course, have an account on the remote system.)

The first thing that might go wrong is that you may run into server access control. If you see the following error:

Xlib:  connection to "sapphire:0" refused by server
Xlib:  Client is not authorized to connect to Server
Error: Can't open display: sapphire:0

you can probably fix it by typing xhost +ruby in a sapphire window and running the command again on ruby.[34]

[34]The security-conscious may prefer to use the fully qualified domain name on the xhost command line (such as xhost +ruby.oreilly.com).

Once you have networking and access control issues solved, you should be able to display clients from the remote machine. The next issue is how to run remote clients easily.

If you have ssh (Section 1.21), its X forwarding handles authorization (setting DISPLAY) and also encrypts the connection to make it secure. Here's an example using ssh for an interactive login:

sapphire:joan % ssh ruby
joan's passphrase:
Last login: Mon Mar 12 16:27:23 from sapphire.oreilly.com
NetBSD 1.4.2A (ORA-GENERIC) #6: Wed May 31 06:12:46 EEST 2000

TERM = (vt100) xterm

ruby:joan % xload &

6.10.2. Starting a Remote Client with rsh and ssh

If you have ssh, that's the easiest way to start a remote client:

sapphire:joan % ssh ruby -n xterm &

If you aren't running an SSH agent, you'll need to enter your password before the remote command can run. If you have trouble, try the ssh -f option -- with no ampersand (&) at the end of the command line.

If you don't have ssh, the best way to start a remote client is the same way you'd start any remote command: using the rsh command:

sapphire:joan % rsh ruby -n xterm -display sapphire:0

There are a few issues to be ironed out first, though.

To run rsh successfully, make sure that you have permission to run remote shells on the remote machine. This means that the local machine must be listed either in the remote machine's /etc/hosts.equiv file or in your personal $HOME/.rhosts file on the remote machine. For example, an .rhosts file might read:


If the host is properly set up on the remote machine, then rsh will execute properly, and rlogin will no longer ask for a password when you try to connect to the remote machine. If it is not set up properly, then rlogin will prompt for a password, and rsh will fail with the message Permission denied.

Using .rhosts or /etc/hosts.equiv for this purpose might be considered a breach of security: it means that if someone breaks into your account on one machine, he can break into your account on all other machines as well. Clearly, you want to be careful what hosts you list in .rhosts. For that reason, it's better to use the fully qualified domain name (i.e., harry.ora.com instead of just harry).

There are a few more rules:

ssh expects slightly different files than does rsh, although the server may be configured to allow the use of both .rhosts and .shosts, as well as the system-level /etc/hosts.equiv and /etc/ssh/shosts.equiv files. Many administrators have wisely chosen to avoid rsh and related commands altogether, even to the point of disallowing fallback to rsh from a ssh login attempt. More information about the peculiarities of ssh may be found in Chapter 51.

--LM, EP, JP, and SJC

Library Navigation Links

Copyright © 2003 O'Reilly & Associates. All rights reserved.