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.
One Comment
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.
Post a Comment