Using xauth

xauth is an X Window utility for displaying locally the output of an X Window application running remotely. xauth serves the same purpose as the older xhost utility, but is considered far more secure. Under xauth a 'magic cookie', encoding information about your password and your current login session, must be found in the home directories of both your local and remote machines before one machine can display remotely on the other. This 'cookie' is stored in a file in your home directory called .Xauthority. Note that because this file is basically a password to your X Window display you must not give it group or world read or write permissions. The correct permissions for this file are read and write for you only, or 600 in octal. The presence of other than 600 permissions is cause for immediate account inactivation.

Use

To direct the display of an X-Window application running remotely on an ARSC SGI workstation to your local ARSC SGI workstation:

Since all ARSC SGI workstations (with the exception of grizzly) share the same NFS-mounted home directories, the .Xauthority file is visible to each machine, and the process of setting up a remote display is as simple as setting your DISPLAY variable. To run an X Window application on onyx2 and have it display on indigo43, for example, you would take the following steps:

To direct the display of a remote X-Window application to your local ARSC SGI workstation from a workstation which is not an ARSC SGI workstation, but to which you have rsh access:

The procedure for remote displays between two machines not sharing the same home directory is more involved, since it is necessary to transfer the 'magic cookie' from one machine's .Xauthority file to the other's. This can be done relatively simply, however, if you can run a remote shell on the remote machine. Generally, for non-ARSC systems, this would require that you have an .rhosts file in your home directory on the remote machine with an entry consisting of your local machine name and userid. ARSC systems use kerberos for authentication and do not need .rhost files. Then to run an X Window application on chilkoot, and have it display on indigo43, for example, you would take the following steps:

To run an X Window application on a non-ARSC machine, and have it display on indigo43, for example, you would take the following steps:

Notes on errors:

If you get a 'xauth: not found' error, either use the full path to xauth (/usr/bin/X11/xauth on the SGIs), or for a more permanent solution, add the xauth path to your PATH variable.
In C shell:

add the following line to your .cshrc file:
```
    setenv PATH ${PATH}:/usr/bin/X11
```
then cause your change to take effect:
```
    source .cshrc
```
In Korn shell:

add the following line to your .profile file:
```
         export PATH=${PATH}:/usr/bin/X11
```
then cause your change to take effect:
```
         . .profile
```
If you receive a permission denied error message when attempting to rsh to another machine, check your .rhosts file. If you do not have your local machine name and local userid in your remote .rhosts file, then change the permissions on the .rhosts file to allow you to write to it (use chmod 600 .rhosts), edit the file (adding your local machine name and userid), then exit your editor and remove write permissions from your .rhosts file (chmod 400 .rhosts). If the &quotremote machine" is chilkoot, chilkoot will deny rsh access any time the file permissions include group or other read/write (even if the contents of the .rhosts file is correct).
If you get a login incorrect error message when attempting to rsh to another machine, it may be due to having different userids on the two machines. If your userid on the remote machine is fsabc, for example, add -l fsabc to the rsh command (immediately following, as in /usr/bsd/rsh -l fsabc ...).

To direct the display of a remote X-Window application to your local computer from a remote computer to which you do not have rsh access:

As in the previous case, it is necessary to transfer the magic cookie from one machine's .Xauthority file to the other's. Without the ability to open a remote shell on the remote machine, you will have to move the cookie over manually and merge it into the remote machine's .Xauthority file. To run an X Window application on video1 and have it display on grisly.cameron.edu, for example, you would take the following steps:

* Note that the cookie file contains all the information needed to access your X Window display. This is the reason why it should be deleted after use, or at a minimum checked to ensure that only you have read and write permissions for this file (octal 600).

Notes on errors:

If you get a xauth: not found error, either use the full path to xauth (/usr/bin/X11/xauth on the SGIs), or for a more permanent solution, add the xauth path to your PATH variable.
In C shell:

add the following line to your .cshrc file:
```
    setenv PATH ${PATH}:/usr/bin/X11
```
then cause your change to take effect:
```
    source .cshrc
```
In Korn shell:

add the following line to your .profile file:
```
         export PATH=${PATH}:/usr/bin/X11
```
then cause your change to take effect:
```
         . .profile
```

Using xauth

Contents

Introduction

Use

To direct the display of an X-Window application running remotely on an ARSC SGI workstation to your local ARSC SGI workstation:

To direct the display of a remote X-Window application to your local ARSC SGI workstation from a workstation which is not an ARSC SGI workstation, but to which you have rsh access:

Notes on errors:

In C shell:

In Korn shell:

To direct the display of a remote X-Window application to your local computer from a remote computer to which you do not have rsh access:

Notes on errors:

In C shell:

In Korn shell: