Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

A solution for X11 forwarding on AFP OS X clients OS X Server
When ssh'ing into an OS X client as a user whose home directory is mounted on an AFP server, the following errors can occur. First, during the login process:
/usr/X11R6/bin/xauth: error in locking authority file ~/.XAuthority 
Second, if one tries to start an X11 application, the following error occurs:
X11 connection rejected because of wrong authentication. 
X connection to localhost:10.0 broken (explicit kill or server shutdown).
The problem seems to be that xauth cannot update the .Xauthority file when the ssh session starts up, rendering the user unable to authenticate to the X server connected to their ssh session. A workaround to this problem is to have xauth write the session authnetication cookie info to a file on the local disk, not in the AFP-mounted home directory. One needs to create an /etc/sshrc file to do this.

Afterwards, the user's shell environment needs to be updated to point X to the proper file to obtains it authority data. The following are the changes I made to my clients to get X11 forwarding working on these machines:
#########################################################
# /etc/sshrc

# Set up the local file in which to store the .Xauthority information:
export XAUTHORITY=/tmp/.Xauthority.$USER

# Now create and write the magic cookie information:
if read proto cookie && [ -n "$DISPLAY" ]; then
   if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
      # X11UseLocalhost=yes
      echo add unix:`echo $DISPLAY |
      cut -c11-` $proto $cookie
   else
      # X11UseLocalhost=no
      echo add $DISPLAY $proto $cookie
   fi | /usr/X11R6/bin/xauth -q -
fi
#########################################################
The user needs to have the proper .Xauthority file location set up when their shell starts up. The users in my group have bash as their default shell, and the additions to their ~/.bashrc script needed to set up X11 correctly are as follows:
###########################################################
# ~/.bashrc X11 configuration
if [[ -z $DISPLAY ]]; then
   # DISPLAY is not set, so check to see what X display is owned
   # by the current user and set DISPLAY to this value: 
   X11_FOLDER=/tmp/.X11-unix
   currentUser=`id -u`
   bb=`ls -ln $X11_FOLDER | grep $currentUser`
   bbb=${bb/*X/:}
   usedDISPLAY=$bbb.0
   export DISPLAY=$usedDISPLAY
else
   # DISPLAY is set, so we assume remote user login via
   # ssh and set the XAUTHORITY variable to point to 
   # proper file.
   export XAUTHORITY=/tmp/.Xauthority.$USER
fi
###########################################################
With these changes, ssh users should be able to use X11 programs.
    •    
  • Currently 1.80 / 5
  You rated: 2 / 5 (10 votes cast)
 
[16,582 views]  

A solution for X11 forwarding on AFP OS X clients | 3 comments | Create New Account
Click here to return to the 'A solution for X11 forwarding on AFP OS X clients' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A solution for X11 forwarding on AFP OS X clients
Authored by: estadtherr on Apr 14, '06 02:45:11PM

I think the "-Y" option to ssh accomplishes the same thing:

     -Y      Enables trusted X11 forwarding.


[ Reply to This | # ]
A solution for X11 forwarding on AFP OS X clients
Authored by: zauhar on Nov 20, '06 12:45:17PM

Sorry, but what the author suggests is NOT equivalent to -Y. The problem has to do with some access problem to the .XAuthority file over AFP-mounted home directories. In my hands the approach as posted works, and was a life-saver!

Note to non-X11-gurus - remember that in X11 parlance the "server" is the machine that you tend to think of as the client.

---
Randy J. Zauhar, PhD
Assoc. Prof. of Biochemistry
Director, Graduate Program in Bioinformatics
Dept. of Chemistry and Biochemistry
University of the Science



[ Reply to This | # ]
A solution for X11 forwarding on AFP OS X clients
Authored by: Craig Jones on Jun 16, '08 11:04:21AM

It appears that something like this is needed in 10.5 as well (at least, I needed it to get X11 working).



[ Reply to This | # ]