Re: CVS trunk emacsclient: X11 connection rejected

[Stefan Monnier]

>>> X11 connection rejected because of wrong authentication.
>>> *ERROR*: Connection lost to X server `localhost:10.0'
>> 
>> It's strange you get such an error: it seems to indicate that SSH
>> did do X11 forwarding, proiperly set the $DISPLAY envvar, but
>> somehow the corresponding Xauth key didn't get to ~/.Xauthority
>> file, or else your Emacs server somehow fails to find this key
>> (maybe it doesn't re-read the .Xauthority file?). Could you
>> investigate a bit more?

> Should I be trying to debug ssh or Emacs, or both? `ssh -vvv' doesn't
> tell me much. Some snippets:

Both?

> debug1: Authentication succeeded (hostbased).
> debug1: channel 0: new [client-session]
> debug3: ssh_session2_open: channel_new: 0
> debug2: channel 0: send open
> debug1: Entering interactive session.
> debug2: callback start
> debug2: x11_get_proto: /usr/bin/xauth  list unix:10.0 2>/dev/null
> debug1: Requesting X11 forwarding with authentication spoofing.
> debug2: channel 0: request x11-req confirm 0
> [...]
> debug1: Sending command:
> /scratch/gmorris/emacs/cvs/trunk/lib-src/emacsclient --no-wait
> /scratch/gmorris/emacs/cvs/trunk/README
> debug2: channel 0: request exec confirm 0
> debug2: fd 3 setting TCP_NODELAY
> debug2: callback done
> debug2: channel 0: open confirm rwindow 0 rmax 32768
> debug2: channel 0: rcvd adjust 131072
> debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
> debug1: client_request_x11: request from 127.0.0.1 36444
> debug2: fd 7 setting TCP_NODELAY
> debug2: fd 7 setting O_NONBLOCK
> debug3: fd 7 is O_NONBLOCK
> debug1: channel 1: new [x11]
> debug1: confirm x11
> debug2: X11 connection uses different authentication protocol.
> X11 connection rejected because of wrong authentication.
> debug2: X11 rejected 1 i0/o0

> If I do something like:
host2> ssh -vvv host1 xterm

> then the debug output looks basically the same up to the successful
> creation of an xterm at "confirm x11".

I'm not sure i understand what the above refers to.  Does the debug output
correspond to a run of `ssh' where ssh runs `emasclient' where the second
one runs `xterm'?  What about an `ssh -vvv' that runs `emacs'?

Can you check the .Xauthority file and XAUTHORITY envvars?
Basically compare their value in the `emacs' process from their value at the
other end of the `ssh' tunnel: ssh normally creates a new Xauthority cookie
for the "localhost:10" proxy display.  It can then either place it in
~/.Xauthority or in some other file, in which case it needs to set the
XAUTHORITY envvar, but then the `emacs' process won't know about it.

>> It's a change introduced by the multi-tty code.  You can override it in
>> various ways, such as:
>> 
>> ssh host1 emacsclient --display :0 --no-wait $PWD/README

> If I use this method, my original Emacs instance pops up a new frame
> (this is emacs -Q, so it should not do this AFAIK),

This is probably because your current DISPLAY is not ":0" but something
slightly different, like ":0.0".
Take a look at M-: (frame-parameter nil 'display) RET
and then try the above test with that display argument.
server.el should probably try to normalize the DISPLAY value, but I'm not
sure what kind of normalization should be performed, so if you can tell us
what is your situation, maybe we can get the code to DTRT for you.

> but doesn't visit the specified file (at all).

That's a bug.  What happens to the frame that pops up?  Does it stick
around, displaying some unrelated buffer?  Or does it disappear?  Is the
buffer displayed elsewhere?  Is the buffer not displayed but kept (i.e. it
appears in the buffer list)?


        Stefan