X11 forwarding is broken after SUDO SU – - Page 2

miedward · 02-20-2007, 12:31 AM

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.

jlightner · 02-20-2007, 09:53 AM

Maybe I need to check it out on my HP-UX boxes. My verification was done on Linux.

jlightner · 02-21-2007, 02:29 PM

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.

donax · 09-17-2009, 03:15 PM

Quote:

Originally Posted by miedward

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...

#echo $DISPLAY
localhost:10.0
#su -
#cp /home/username/.Xauthority .
#chmod 600 .Xauthority
#DISPLAY=localhost:10.0
#export DISPLAY
#xterm

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

aptitude install xbase-clients

:-)