From my own notes on this subject....

Methods to automatically passwd Authorization from one machine to another.
  This also includes the problem of notifing the remote host of the current
DISPLAY that is being used.

1/ Use rsh/rexec/on...  (the method in the xauth manual)
      Set up the your .rhosts file in the home directory on the remote
  machine so that a password in not required to remotly execute commands.

         xauth extract - $DISPLAY | rsh other xauth merge -

  This method is also used by xrsh to pass authorization. My vampire
  program also uses a variation, however I wrap it as part of the remote
  command sequence  (EG:  xauth add $auth)

     Included in this method is the use of `xrlogin' and `xrsh' to do
  this job for you. These programs usally (the newer ones that is) allow
  you to pass a secified list of ENVIRONMENT variables which includes
  the `DISPLAY' and/or a copy of the authorization code required.

     The `xon' program available (if enabled) on sun machines will also
  pass environment variables, as well as the current directory.  You will
  however be required to store the Authority in such a variable for
  passing. Unless you are also have shared home directories.

    WARNING: Environment variables and command line arguments are visible
  in `ps' listing with the appropiate flags. As such passing authorization
  information in environment variables or as arguments is not recomended.
  The recommended method as given in the manual (shown above) is safe from
  the view of other users.

2/ Wrap it as part of the TERM environment variable.
      This method uses the fact that most remote command executors do pass
  the TERM environment variable to the remote host. It is then a matter of
  an appropiate script in your remote .login file to extract the information
  from the TERM environment variable and set up things appropiatly.
    A version of the xrlogin script is available on the network which does
  this. Basically you change the TERM environment variable before the
  actual call to rlogin is performed, to include your DISPLAY and your
  authorization.
    On the remote machine you then extract this information and return the
  TERM environment variable to normal BEFORE you use it for reseting or
  stty'ing your terminal.

  ---8<---
  script for launching rlogin:
    #!/bin/sh
    # ~/bin/rl   --- Rlogin with display:
    if [ -n "$DISPLAY" ]; then
      case "$DISPLAY" in
        :*) DISPLAY=`hostname`$DISPLAY ;;
      esac
      TERM="$TERM&$DISPLAY&`xauth nextract - $DISPLAY`"
      export TERM
    fi
    rlogin $*
  ---8<---
  add to your .cshrc or .login
    if ( $?TERM ) then
      if ( `echo $TERM | tr -cd '&'` != '' ) then
        echo "$TERM" | cut '-d&' -f3 | xauth nmerge -
        setenv DISPLAY `echo "$TERM" | cut '-d&' -f2`
        setenv TERM    `echo "$TERM" | cut '-d&' -f1`
      endif
    endif
  ---8<---
  xterm command to use
    xterm -T hostname -e ~/bin/rl hostname
  ---8<---

3/ NFS.
     Write it to a file on a shared NFS partition you have access to.
   Note that if the home directories are NFS mounted, then authorization
   is automatically passed, Hoever you will still have to pass your
   DISPLAY environment variable via a file or other means. IE:

      login host:       echo $DISPLAY > ~/.X11host
      remote host:      setenv DISPLAY `cat ~/.X11host`

4/ Finger for the info in a .plan file
      This involves encrypting the information into your `.plan' or
  `.project' and having the remote machine finger for the information.
  This has the disadvantage of having the information to anyone fingering
  the user.  Thus requiring a encryption method that is uniq to each
  individual.  IE: the method of decyrption must not be shared or known
  by others, nor should it be easy to determine.
    A improvment is to use the `who fingered me' technique to only give
  the information only to your own remote accounts and not just to anyone
  who is asking.
    This last method was developed last year by a second year here, untill
  I explained to him the need for the encryption, at which point he gave
  up this method. It is however a valid method. It is easer than (2) but
  less secure.


  Anthony Thyssen - (SysProg @ Griffith University)     anthony@cit.gu.edu.au
------------------------------------------------------------------------------
    "Magic is Real -- unless declared an integer"  ---  John P.Melvin