One thing that troubled me moving to Ubuntu 9.10 Karmic Koala: my remote X applications stopped working with the error
X11 connection rejected because of wrong authentication
The reason seems to be that Gnome moved the location of X authorization to [wherever-the-hell-i-dont-remember], whereas ssh and everything else still use the same location (~/.Xauthority). Note: I clearly forgot whatever it was I discovered about xauth, so please enlighten me in the comments, and I will update this exceedingly lame paragraph.
This is going to be tagged as an Emacs post because my principal reason to use remote X is Emacs’ awesome make-frame-on-display command.
The bash script I use is saved in ~/bin/xauthmagic:
1 2 | #!/bin/bash xauth -f ~/.Xauthority list | grep -v ':0' | while read foo; do xauth add $foo; done |
This means: look through all the xauth cookies in ~/.Xauthority, remove the ‘:0′ (local) display cookie, take the remaining cookies and run the xauth command on them.
The steps I take to use this:
- On my remote host (emunah), start an ssh section forwarding X:
greg@emunah$ ssh greg@maui -Y
-
On my local host (maui), run the
xauthmagicscript abovegreg@maui$ ~/bin/xauthmagic
-
From my local host emacs, run
M-x make-frame-on-display RET localhost:10.0 RET
Et voilá!
5 Comments
Greg, I have this same problem, too. Is this xauth stuff really the “official” solution? I unfortunately know nothing about xauth.
I can ssh to my remote box with X forwarding and run “xeyes” just fine, and even emacs runs fine. My only problem is when I run emacsclient and try to create a new frame, I get the same error as you… I will try your solution! Thank you!
P.S. Everything did work fine until the upgrade to karmic…
@erikr, I have logged on to several Linux machines to determine their default Xauthority database location, using xauth -v. On Debian machines, I always get ~/.Xauthority. I get that result even on a server that has been upgraded to Karmic, but which does not have Gnome. On my laptop, however, I get /var/run/gdm/auth-for-gregj-3sy6gB/database. That path changes every time I log in, with different salt. Since everything else looks to your home .Xauthority file, this causes your emacsclient session to fail to authenticate.
I might try messing around with setting the XAUTHORITY environment variable, but I’m not sure that would work for Gnome.
Howdy,
I’ve been working on this same problem too. I submitted an Emacs
bug(#5434) and was given this explanation by one of the respondents:
,—-
|
| > Okay, I’ll try that, but a quick question: should an xauth problem result
| > in failures for every X application I try to run? Other applications
| > (other than emacsclient) run just fine.
|
| There is a difference. When you start other clients, you do it from
| the shell started by the ssh login process. When you do emacsclient
| -c it only tells your emacs daemon to open a frame on your DISPLAY.
| The emacs daemon is not started from your ssh shell.
|
| Try starting another X client from a shell not related to the ssh
| shell with the ssh-forwarded display (localhost:10) and see what you
| get. You should get permission denied. But your Emacs daemon may
| have other displays opened, that can influence matters also.
`—-
All my machines (two Fedora 12, one Ubuntu Karmic Koala) have the
newest gnome, and I confirm the same bizarre xauth locations as you
do.
I’m at least glad I’m not the only one!
Joel
It works!
I am not absolutely certain this is correct, but it has worked for me.
The problem I wanted to solve was to ssh from my laptop to a ubuntu server and then invoke emacsclient to obtain a x window’s frame on my lap top served up from the emacs running on the ubuntu server. The xauth inside emacs is the one into which I needed to add the xauth credentials. The following worked, at least once
This script resides on the ubuntu server is run after you ssh to the server, forwarding your
laptop’s X display.
Thanks for the hint!