Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
Click here to see the post LQ members have rated as the most helpful post in this thread.
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.
Last edited by MensaWater; 02-21-2007 at 01:42 PM.
When you open an X forwarding connection (or any X connection) information about that session is put in $HOME/.Xauthority which should only be readable by that user and root. Really, you should check and make sure (more about this again later), because if anyone else can read this file, they can hijack your X connection and do all sorts of exciting things like keystroke logging et cetera because all X11 information is sent unencrypted.
So, what you can do (besides just using "su" which preserves the prior users environment, so avoids the problem) is something like the following...
This should give you your xterminal on the original client display. There are lots of ways to do this, some probably more secure (and certainly many more elegant) than this, but as long as you REMEMBER TO CHMOD THE COPIED .Xauthority FILE this should be as secure as anything else, I think. Probably should delete it after you are done, just for fun.
This works fine for me. Sudo is necessary when you have access to sudo but do not have the root password.
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
That will create a file called xuser each time you log in, containing the xauth string. Now su and add this to /root/.bashrc:
Code:
XUSER=`who -m | awk '{print $1}'`
XUSERHOME=`grep ^$XUSER: /etc/passwd | awk -F: '{print $6}'`
if [ -s "$XUSERHOME/xuser" ]; then
. $XUSERHOME/xuser
echo Added xauth tokens for display for $XUSER
else
echo Original user $XUSER left no indication of X job
fi
That will pick up the authentication needed from the username you logged in as, and let you run X applications as root after logging in with your own username from another machine. It's probably horribly insecure, but as the designers of ssh, su, and X didn't think to provide for this very common requirement, it's the only workable solution I know.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.