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

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

>     sapphire.ora.com
>     harry.ora.com

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:

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

--LM, EP, JP, and SJC

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