Getting X11 forwarding through ssh working after running su

Posted by daveseff on Mon 29 Jan 2007 at 06:06

Tags: ,
X authentication is based on cookies -- secret little pieces of random data that only you and the X server know... So, you need to let the other user in on what your cookie is. One way to do this is as follows:
Before you issue the su or sudo (but after having ssh'ed into the remote system), request the cookie for the current DISPLAY that's connecting to your X server:

$ xauth list $DISPLAY
You'll get something like

somehost.somedomain:10 mit-magic-cookie-1 4d22408a71a55b41ccd1657d377923ae

Then, after having done su, tell the new user what the cookie is:

$ xauth add somehost.somedomain:10 MIT-MAGIC-COOKIE-1 4d22408a71a55b41ccd1657d377923ae

(just copy'n-paste the output of the above 'xauth list' onto 'xauth add') That's it. Now, you _should_ be able to start any X application.

 

 


Posted by Anonymous (82.241.xx.xx) on Mon 29 Jan 2007 at 06:28
You can use the sux package too (with the command of the same name).

[ Parent | Reply to this comment ]

Posted by Anonymous (74.104.xx.xx) on Mon 29 Jan 2007 at 17:35
And similarly there is a gksu package that provides gksu and gksudo.

[ Parent | Reply to this comment ]

Posted by k8to (64.142.xx.xx) on Wed 31 Jan 2007 at 12:22
Although it is a crying shame that gksu as packaged on debian is in the same package as gksudo, which pulls in sudo with all the nasty configuration and ugly behavior. NO sudo on my computers, please!

[ Parent | Reply to this comment ]

Posted by Anonymous (212.23.xx.xx) on Mon 29 Jan 2007 at 09:47
Another technique I discovered recently (after getting stuck on a SLES system with no sux packages) is to set the XAUTHORITY environment variable to $USER/.Xauthority (where $USER is the username you ssh'd in as).

[ Parent | Reply to this comment ]

Posted by tong (69.63.xx.xx) on Wed 31 Jan 2007 at 03:03
[ View Weblogs ]
Another technique ... is to set the XAUTHORITY

Please elaborate when and where do you do that, and under what conditions.

because I really doubt that it will work. ~/.Xauthority is most often of "-rw-------" attribute. nobody else except root can access it. Let alone we are talking about ssh to another box here.

but I maybe wrong, and would like to listen.

thanks

[ Parent | Reply to this comment ]

Posted by Anonymous (194.178.xx.xx) on Tue 6 Feb 2007 at 17:59
"~/.Xauthority is most often of "-rw-------" attribute. nobody else except root can access it"

You are not right. Nobody else but root and the _user_ owning the file can access it. And the user owning the file is .... who?

[ Parent | Reply to this comment ]

Posted by Anonymous (194.178.xx.xx) on Tue 6 Feb 2007 at 17:55
I'm pretty sure you do not mean "$USER/.Xauthority", but "$HOME/.Xauthority". Where $HOME is the home of $USER. And $USER is the username you ssh'd in....

[ Parent | Reply to this comment ]

Posted by lpenz (200.213.xx.xx) on Mon 29 Jan 2007 at 15:30
Another really really simple alternative is to ssh again to root@localhost.

[ Parent | Reply to this comment ]

Posted by busfault (69.205.xx.xx) on Fri 2 Feb 2007 at 18:58
[ View Weblogs ]
Would that be a good idea though? That would require enabling root login through ssh. At which point why not just ssh into the machine with root to begin with? Is it possible to deny foreign ssh as root but accept local ssh as root?

[ Parent | Reply to this comment ]

Posted by drgraefy (128.59.xx.xx) on Mon 29 Jan 2007 at 18:51
[ View Weblogs ]
My first reaction to this is "ack! why are you opening x clients as root!?" but i guess you could be su'ing to another non-root user.

I definitely agree with the previous commenter, though, that the easiest thing to do is to just ssh again into the account of the local user with whom you want to open the x clients.

[ Parent | Reply to this comment ]

Posted by daveseff (208.251.xx.xx) on Mon 29 Jan 2007 at 19:03
I didn't say anything about root. Root is easy. You usually can run 'sudo xapplication' and be happy with that. As an administrator, which is what this site is about, sometimes you have to help troubleshoot things for other users and you need to 'sudo su - username' to see the problem from their perspective. When you sudo su, or su in general you loose your DISPLAY and Xauth settings.

[ Parent | Reply to this comment ]

Posted by Anonymous (24.10.xx.xx) on Tue 30 Jan 2007 at 22:10
"My first reaction to this is "ack! why are you opening x clients as root!?" but i guess you could be su'ing to another non-root user."

Erm... Because some X clients are root only? Such as some system configuration GUI tools for example...

Or sometimes you need to use a GUI tool (for convenience sake) such as kompare on files only accessible by root?

Admittedly, MOST of the time it's unwise to run X clients as root, but that doesn't mean it's ALWAYS a bad idea. It's not utterly taboo or anything. Just not always the best plan as a first option. Better avoided if other options are available.

[ Parent | Reply to this comment ]

Posted by Anonymous (66.183.xx.xx) on Fri 8 Jun 2012 at 06:05
Also sometimes not all users are allowed to login ssh. In my case I only allow users with limited rights and strong security ssh but sometimes I want to ssh then su to a 'Desktop' user. This was exactly what I needed. I just use sux. (great memorable name!)

[ Parent | Reply to this comment ]

Posted by Anonymous (198.45.xx.xx) on Mon 29 Jan 2007 at 21:24
I don't believe the timing of this article! :)

I'd been struggling with this recently:

I can't login as user B directly on a Solaris box.

I login as user A, then su to B. Of course, X forwarding stops working. And I need X working to install some proprietary software.

Then I see this article that explains precisely how!

Thanks!

[ Parent | Reply to this comment ]

Posted by Anonymous (194.78.xx.xx) on Tue 30 Jan 2007 at 06:35
#Asssuming you did
ssh -X user@hostname

# Gain root privileges,
su -

# and merge the Xauth information like this:
xauth merge /home/user/.Xauthority

Cheers,


Benoît

[ Parent | Reply to this comment ]

Posted by tong (63.243.xx.xx) on Wed 31 Jan 2007 at 14:38
[ View Weblogs ]
will the trick works on chroot as well, provided everything eg /dev /proc are properly bind mounted?

Having done "xauth add" my DISPLAY is still empty, and

$ xauth list

seems to takes years to report the cookie...

[ Parent | Reply to this comment ]

Posted by daveseff (208.251.xx.xx) on Wed 31 Jan 2007 at 14:43
I believe xauth is for X11 authentication. Once you run dchroot, you may have to set you DISPLAY to :0.0 or localhost:10.0 depending on where you are. Once the variable is set, you should be ok.

I may be wrong as my experience with chroot is limited.

[ Parent | Reply to this comment ]

Posted by tong (63.243.xx.xx) on Wed 31 Jan 2007 at 14:44
[ View Weblogs ]
Yep, it works, after I bind mount /tmp as well!!!

[ Parent | Reply to this comment ]

Posted by Anonymous (82.180.xx.xx) on Fri 23 Feb 2007 at 22:39
on debian etch testing I did...

ssh ip -X -l snot
echo $DISPLAY
copy the output
su -
cat /home/snot/.Xauthority >.Xauthority
export DISPLAY="paste the output of echo $DISPLAY here... without quotes"

not pretty but it works...

[ Parent | Reply to this comment ]

Posted by Anonymous (134.226.xx.xx) on Mon 26 Feb 2007 at 15:33
You'll need to set the DISPLAY environmental variable after doing the su command in order for this to work.

[ Parent | Reply to this comment ]

Posted by Anonymous (95.247.xx.xx) on Sun 15 Aug 2010 at 10:55
Hi

When I type "xauth list $DISPLAY"

nothing comes up. So I cannot move on to the next command line and type the cookie number.

Is there any other way to arrive at the same results?

Thanks a lot

you can respond to bruno.tremblay@mcgill.ca

[ Parent | Reply to this comment ]

Posted by Anonymous (69.236.xx.xx) on Sun 29 Aug 2010 at 08:15
I had the same problem. It turns out DISPLAY may be set to "localhost:10.0" but the cookie may be stored under a different name variation of display 10 (like jupiter.x.com/unix:10)

Before su:

-to get a list of cookies for each display.
linux> xauth list
jupiter.x.com/unix:14 MIT-MAGIC-COOKIE-1 ec0778f78a8b342429399eba5ff2632e
jupiter.x.com/unix:16 MIT-MAGIC-COOKIE-1 82a777aa883decc099dfb88ad5c1cf7a
jupiter.x.com/unix:15 MIT-MAGIC-COOKIE-1 f4abb7722882168eb3c145b3c926cb53
jupiter.x.com/unix:11 MIT-MAGIC-COOKIE-1 ff99c450ff208f66332a12e8bdb3a8c6
jupiter.x.com/unix:10 MIT-MAGIC-COOKIE-1 6f640f12f809c265968828c983661afc

-find out your display
linux >echo $DISPLAY
localhost:10.0

-do your su

linux> su -l user_i_want_to_be

-now set the cookie to the number matching your display (in my case 10)

linux> xauth add jupiter.x.com/unix:10 MIT-MAGIC-COOKIE-1 6f640f12f809c265968828c983661afc

[ Parent | Reply to this comment ]

Posted by Anonymous (153.96.xx.xx) on Fri 6 May 2011 at 12:46
If the DISPLAY variable isn't set and all config seems to be right, check if there is a valid loopback device on the server side. For Debian: look at /etc/network/interfaces and add "auto lo" and "iface lo inet loopback". Additionally check /etc/hosts for lo.

[ Parent | Reply to this comment ]

Posted by Anonymous (192.8.xx.xx) on Fri 6 Apr 2012 at 05:31
I was not able to add the cookie for the root to the user using "xauth add ...."
I can execute the "xauth add ...." command. But if search using "xauth list", it will still be empty, the .Xauthorization file remain unchanged.
Not sure why the "xauth add ...." doesn't work

Finally I solved the problem by copying the .Xauthorization of the root to the user home folder.

[ Parent | Reply to this comment ]

Posted by Anonymous (132.239.xx.xx) on Tue 28 Aug 2012 at 19:18
I had the same problem! Thanks for the idea! You saved me from getting some more grey hair!

[ Parent | Reply to this comment ]

Posted by Anonymous (125.237.xx.xx) on Fri 8 Feb 2013 at 01:45
If you have to setup Xauth or futz with $DISPLAY after using sudo or su in a ssh -X session, it should work but the display traffic is not going through the ssh tunnel, it is just going around the tunnel and through unencrypted Internet.

I believe that if you ssh -X to a host and then "sudo bash" the X11 gui will display properly through the encrypted and compressed ssh tunnel. This works on both linux and Solaris 11

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

What do you use for configuration management?








( 102 votes ~ 0 comments )