Interesting, this is yet another subtle difference between how things are handled on Solaris and Linux servers (at least the ones I work with). When I ssh into to a Solaris server, I always need the .Xauthority information from the original user or I get the MAGIC COOKIE error the original poster mentioned.
That explains why all the references to this issue were for Solaris, which I thought was unusual, but didn't look into carefully. All my Linux servers have heads, so I don't fiddle around with them over ssh quite as often. Always good to learn where the differences are. |
Maybe I need to check it out on my HP-UX boxes. My verification was done on Linux.
|
Amazing - just a few minutes ago a DBA called about exactly this issue on an HP-UX box. However she was trying to "su - appuser" after logging in as root. (The opposite of what the original poster was doing.)
Using the information about .Xauthority I found the following worked: Login as root echo $DISPLAY cp -p .Xauthority ~appuser ;chown appuser ~appuser/.Xauthority su – appuser export DISPLAY=<value from the echo above> xterm The xterm opened on the tunel I'd opened as root. Of course I did NOT tell the user this because I'd have to get her to remember to clean up .Xauthority for appuser when done to insure no hole was left there. I told the user to ssh in as appuser so that the tunnel created was for appuser rather than for root. I didn't try vice-versa (appuser su - to root) to see if it required this as well. |
Quote:
I think more people might be running as root and then it is not a good idea to "cp /home/username/.Xauthority /root/" Either do "cat /home/username/.Xauthority >> /root/.Xauthority" or more correctly do: su - donax -c " xauth list " > X11auth xauth add $(<X11auth) You may avoid this by changing /etc/sudoers so that it does not change the home directory, or you can manually set set -a HOME=/home/username/ And by the way the xhost command is there to test if the DISPLAY variable and authorization cookies work. Xterm is good, for sure, but is not always present on e.g. Debian installations, like xhost is not always available. In order to install basic X11 clients (programs) on Debian, use aptitude install xbase-clients :-) |
Solution
What I do is this:
In your login directory on the target machine, add this to your .bashrc: Code:
LIVE=`echo $DISPLAY | awk -F: '{print $2}' | awk -F. '{print $1}'` Code:
XUSER=`who -m | awk '{print $1}'` |
I prefer this method (for sudo):
In ROOTS .bashrc add: XAUTHORITY=/home/$USER/.Xauthority (If no root access to homedirs (nfs mounts, etc.) chmod 777 .Xauthority file in users homedir - and change back when done. Redhat 6.1 auto-chmods the file back to protected on next login. |
Useful info but this is a VERY OLD THREAD. Please think twice before replying.
|
All times are GMT -5. The time now is 04:10 PM. |