thefoggiest.dev

X Forwarding and sudo

I administrate a remote linux machine of someone I know who now and then needs me to help him out. To find out if applications actually work, I use X forwarding. To do that, the remote box has X forwarding enabled, by having this line in its /etc/ssh/sshd_config:

X11Forwarding yes

Then I use:

me@localbox:~$ ssh -X remotebox

to log in at the remote machine, and then I can use whatever X application I like, and it will display on my local monitor. But whenever I become another user on that machine, using su or sudo, X forwarding stops working, with these messages:

X11 connection rejected because of wrong authentication.
Error: Can't open display: localhost:10.0

The reason for this is that

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 (http://www.debian-administration.org/articles/494).

The original user that I used to ssh into the remote machine has such a cookie, but it seems that the other users on that machine can borrow it. Lets say my user on the remote box is called `me’ and the other user is called `otheruser’. Then all I need to do is make the cookie readable by the other user, and make the other user aware of the display and the cookie:

me@localbox:~$ ssh -X remotebox
me@remotebox:~$ chmod 644 .Xauthority
me@remotebox:~$ su - otheruser
Password:
otheruser@remotebox:~$ export DISPLAY=localhost:10.0
otheruser@remotebox:~$ export XAUTHORITY=/home/me/.Xauthority

And then I can happily run x applications as otheruser.


Categorised as: howto, linux


One Comment

  1. Jim Snyder says:

    I have had a long-standing (~months) similar problem on an FC13 box, but your solution didn’t appeal to me because I’m using sudo, not su, and I wouldn’t expect the environment variables to persist across invocations of sudo.

    The very odd thing was, it’s only this one box of 3 or 4 FC13 boxes where I have this problem, ie for all localboxes,

    localbox$ ssh -X remotebox

    followed by (say):

    remotebox$ sudo xeyes

    Just Works(tm) on all the other remoteboxes … but not this one.

    What seems to have fixed the problem is setting the XAUTHORITY environment variable in my .profile for this one box. (Caveat: fixes to problems one encounters with linux utilities bear a striking resemblance to the incantations of the witches in Macbeth, which is to say: Your Mileage May Vary, and indeed Probably Will.)

    It turns out that I’m running a nearly current sudo on this one box, versus the previous sudo release on the other boxes – I had a *different* problem with this sudo release – so I’m guessing that the way sudo handles X authentication changed between these two releases.