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
Password:
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:

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).

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 &

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

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:

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).

• For security reasons, the .rhosts file will be ignored if it is publically writable. Make sure that the .rhosts file is writable only by you.

• Make sure that you are running the correct rsh command. Some systems have a restricted shell, also named rsh. If you get the following error:

  ruby: ruby: No such file or directory

  or:

  ruby: ruby: cannot open

  where ruby is the name of the system that you wanted to run the remote shell on, the problem is probably that you are using the wrong rsh command. Use the which ( Section 1.6) or whereis (Section 1.3) command to see which rsh you are using:

  sapphire:joan % which rsh
  /bin/rsh
  sapphire:joan % echo $path
  /bin /usr/bin /usr/bin/X11 /usr/bsd

  On some System V-derived systems such as IRIX, the restricted shell rsh might live in /bin, while the remote shell rsh (the one you want) resides in /usr/bsd . /bin often shows up in search paths earlier than /usr/bsd, so on those systems you need to redefine your path explicitly so that /usr/bsd is searched before /bin. Alternately, you can supply the full path to the command when you invoke it.

• You may need to append the -n option to rsh to avoid a Stopped error message on some machines.

• You need to be sure that the directory containing X binaries is defined in your search path in your shell setup file (Section 3.3) on the remote system.

• If you are using host-based access control, you need to execute the xhost client to extend access to the remote host before the rsh command is run. Otherwise, clients from the remote host will not have permission to access your display. If you are using user-based access control, you may need to run the xauth command to copy your access code to the remote machine.

• You have to use the -display option in calling a remote shell, or the Can't Open display error will be returned. (Alternatively, you can have your DISPLAY environment variable hard-coded into your shell setup file (Section 3.3) on the remote machine, but this is a very bad idea.) See Section 35.8 for more information on setting your display.

• Be careful not to use unix:0.0 or :0.0 as the display name! Otherwise, the client will display the window on the local display of the remote host. If this succeeds, the user on that display could either become very annoyed or take advantage of the sudden access to your account by reading personal files and sending nasty mail to your boss. You would have no warning; all you would know is that your window didn't appear. So, before running another client, you may want to log in to the remote system and do a ps to ensure that you're not already running the application on the remote display.

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.