CVS trunk emacsclient: X11 connection rejected

CVS trunk emacsclient: X11 connection rejected

[Glenn Morris]

With Emacs 22, and two GNU/Linux hosts with a common (NFS)
file-system, I can do this:

From an X-session running on host1:

host1> emacs -Q -f server-start &
host1> ssh host2
host2> ssh host1 emacsclient --no-wait $PWD/README

which visits the README file in the Emacs running on host1. I often
find this convenient, because I often ssh between various machines and
want to have a single Emacs instance. (The "emacsclient" part is
hidden inside an "emacs" wrapper script that Does The Right Thing
according to the situation.)

If I try the same thing with the CVS trunk, then I get the following
error when trying to run emacsclient:

  X11 connection rejected because of wrong authentication.
  *ERROR*: Connection lost to X server `localhost:10.0'

Is this a multi-tty side-effect, and is there any way around this? Or
should I be doing this a different way now?

(A common file-system is not necessary to see this, you can call
emacsclient to edit eg /tmp/foo.)

TIA.

Re: CVS trunk emacsclient: X11 connection rejected

[Stefan Monnier]

> With Emacs 22, and two GNU/Linux hosts with a common (NFS)
> file-system, I can do this:

>> From an X-session running on host1:

host1> emacs -Q -f server-start &
host1> ssh host2
host2> ssh host1 emacsclient --no-wait $PWD/README

> which visits the README file in the Emacs running on host1. I often
> find this convenient, because I often ssh between various machines and
> want to have a single Emacs instance. (The "emacsclient" part is
> hidden inside an "emacs" wrapper script that Does The Right Thing
> according to the situation.)

> If I try the same thing with the CVS trunk, then I get the following
> error when trying to run emacsclient:

>   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?

> Is this a multi-tty side-effect, and is there any way around this? Or
> should I be doing this a different way now?

> (A common file-system is not necessary to see this, you can call
> emacsclient to edit eg /tmp/foo.)

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
or
   ssh host1 DISPLAY= emacsclient --no-wait $PWD/README

Basically, in Emacs-22 I added the "--display" arg to emacsclient, but made
it default to "nothing" rather than to "$DISPLAY", so you had to use
"--display $DISPLAY" if you wanted to display frames on the current display.
In the multi-tty code, the default has been changed to "$DISPLAY".

My choice for the behavior in Emacs-22 was based on the desire to preserve
the existing behavior.  I'm not sure which of the two is best, but the new
behavior should work about as well usually and better in cases where you use
several different X11 displays on different machines.


        Stefan

Re: CVS trunk emacsclient: X11 connection rejected

[Glenn Morris]

Stefan Monnier wrote:

>>   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:

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".


> 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), but doesn't visit
the specified file (at all).

>    ssh host1 DISPLAY= emacsclient --no-wait $PWD/README

This works. The specified file is visited in the existing frame of the
original Emacs.

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

Re: CVS trunk emacsclient: X11 connection rejected

[Glenn Morris]

Stefan Monnier wrote:

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

OK; I don't really know what to do with the server though.

> 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'?

All the debug output corresponds to ssh running emacsclient. There's a
gap in the middle where I snipped irrelevant info. The debug output
when running xterm is basically the same, without the error at the end.

> What about an `ssh -vvv' that runs `emacs'?

As above, but followed by some stuff that looks like opening and
closing windows and is probably irrevelant. Continuing from where the
last log left off:

debug1: confirm x11
debug2: channel 1: rcvd eof
debug2: channel 1: output open -> drain
debug2: channel 1: obuf empty
debug2: channel 1: close_write
debug2: channel 1: output drain -> closed
debug1: channel 1: FORCE input drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug2: channel 1: input drain -> closed
debug2: channel 1: send close
debug3: channel 1: will not send data after close
debug2: channel 1: rcvd close
debug3: channel 1: will not send data after close
debug2: channel 1: is dead
debug2: channel 1: garbage collecting
debug1: channel 1: free: x11, nchannels 2
debug3: channel 1: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
  #1 x11 (t4 r2 i3/0 o3/0 fd 7/7 cfd -1)

debug3: channel 1: close_fds r 7 w 7 e -1 c -1
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max
16384
debug1: client_request_x11: request from 127.0.0.1 54950
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: channel 1: rcvd eof
debug2: channel 1: output open -> drain
debug2: channel 1: obuf empty
debug2: channel 1: close_write
debug2: channel 1: output drain -> closed
debug1: channel 1: FORCE input drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug2: channel 1: input drain -> closed
debug2: channel 1: send close
debug3: channel 1: will not send data after close
debug2: channel 1: rcvd close
debug3: channel 1: will not send data after close
debug2: channel 1: is dead
debug2: channel 1: garbage collecting
debug1: channel 1: free: x11, nchannels 2
debug3: channel 1: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
  #1 x11 (t4 r2 i3/0 o3/0 fd 7/7 cfd -1)

debug3: channel 1: close_fds r 7 w 7 e -1 c -1
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max
16384
debug1: client_request_x11: request from 127.0.0.1 54951
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

[Emacs ready for use at this point]

> Can you check the .Xauthority file and XAUTHORITY envvars?

On host1, XAUTHORITY=/tmp/.gdmES6K0T. This file has not been updated
for a few hours. There is a separate ~/.Xauthority file, which is
updated by ssh running emacsclient, emacs or xterm.

On host2, XAUTHORITY is unset.

> 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.

ssh is definitely placing things in ~/.Xauthority.

Starting my server Emacs on host1 with an empty XAUTHORITY does not help.

> This is probably because your current DISPLAY is not ":0" but
> something slightly different, like ":0.0".

You are exactly right. :)

> Take a look at M-: (frame-parameter nil 'display) RET and then try
> the above test with that display argument.

It works.

> 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.

On host1, DISPLAY = :0.0
On host2, DISPLAY = localhost:10.0

> 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)?

The frame that pops up persists, displaying the `*scratch*' buffer.
The README file does not appear in the buffer-list at all.
There's no indication Emacs has tried to visit it (nothing in Messages).
The frame that pops up has (frame-parameter nil 'display) == :0

Re: CVS trunk emacsclient: X11 connection rejected

[Stefan Monnier]

> On host1, XAUTHORITY=/tmp/.gdmES6K0T. This file has not been updated
> for a few hours. There is a separate ~/.Xauthority file, which is
> updated by ssh running emacsclient, emacs or xterm.

I see.
So the `emacs' server was run with XAUTHORITY=/tmp/.gdmES6K0T which only
contains keys to contact ":0.0", where the pseudo-display setup by ssh on
localhost:10 uses its own key, stored in ~/.Xauthority.
So the problem is that the `emacs' server can't find the appropriate key
because it's not looking at the right file.

> On host1, DISPLAY = :0.0

Thanks.

>> 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)?

> The frame that pops up persists, displaying the `*scratch*' buffer.
> The README file does not appear in the buffer-list at all.
> There's no indication Emacs has tried to visit it (nothing in Messages).
> The frame that pops up has (frame-parameter nil 'display) == :0

Thanks.  I'll try and see what's going.


        Stefan

Re: CVS trunk emacsclient: X11 connection rejected

[Glenn Morris]

Stefan Monnier wrote:

> So the `emacs' server was run with XAUTHORITY=/tmp/.gdmES6K0T which
> only contains keys to contact ":0.0", where the pseudo-display setup
> by ssh on localhost:10 uses its own key, stored in ~/.Xauthority. So
> the problem is that the `emacs' server can't find the appropriate
> key because it's not looking at the right file.

I did try a test with an unset XAUTHORITY:

host1> XAUTHORITY= emacs -Q -f server-start &
host1> ssh host2
host2> ssh host1 emacsclient --no-wait $PWD/README

and it didn't seem to help. Maybe I should have been setting it to
~/.Xauthority. I can't test this again till Monday now.

Re: CVS trunk emacsclient: X11 connection rejected

[Stefan Monnier]

>> So the `emacs' server was run with XAUTHORITY=/tmp/.gdmES6K0T which
>> only contains keys to contact ":0.0", where the pseudo-display setup
>> by ssh on localhost:10 uses its own key, stored in ~/.Xauthority. So
>> the problem is that the `emacs' server can't find the appropriate
>> key because it's not looking at the right file.

> I did try a test with an unset XAUTHORITY:

host1> XAUTHORITY= emacs -Q -f server-start &
host1> ssh host2
host2> ssh host1 emacsclient --no-wait $PWD/README

> and it didn't seem to help. Maybe I should have been setting it to
> ~/.Xauthority. I can't test this again till Monday now.

Hmm.. so the Xauth key in /tmp/.gdmES6K0T is also in ~/.Xauthority
(otherwise `emacs -Q' wouldn't have been able to open the display)?

What happens if you do

   host2> ssh host1
   host1> echo "$DISPLAY"

and then use this DISPLAY (presumably somehting like "localhost:10"): go to
your Emacs and type

   M-: (make-frame-on-display "localhost:10") RET


        Strefan

Re: CVS trunk emacsclient: X11 connection rejected

[Glenn Morris]

Stefan Monnier wrote:

>> I did try a test with an unset XAUTHORITY:
>
> host1> XAUTHORITY= emacs -Q -f server-start &
> host1> ssh host2
> host2> ssh host1 emacsclient --no-wait $PWD/README
>
>> and it didn't seem to help.

OK, so the above definitely doesn't change anything, I still get "X11
connection rejected".

If instead I unset XAUTHORITY before starting Emacs, or set it to
~/.Xauthority, then `ssh host2' warns "No xauth data; using fake
authentication data for X11 forwarding.". I can still open xterms,
emacs, etc. Now the emacsclient command (with no display option) shows
the behaviour of popping up a new frame of the server Emacs showing
scratch, and not visiting the specified file at all.

> What happens if you do
>
>    host2> ssh host1
>    host1> echo "$DISPLAY"

Is that meant to be that way round? I should have used better names
than "host1", "host2". :)

host1 is the local host, running the X session, host2 is a remote host.

> and then use this DISPLAY (presumably somehting like "localhost:10"): go to
> your Emacs and type
>
>    M-: (make-frame-on-display "localhost:10") RET

Assuming you meant:

host1> ssh host2
host2> ssh host1 'echo $DISPLAY'   # localhost:10.0
host2> emacs -Q --eval '(make-frame-on-display "localhost:10.0")'

then it works. If you wanted me to ssh to host1 and start an Emacs
there, then it also works.

If you wanted me to start an Emacs on host1 before `ssh host2', then
it's unresponsive for a few seconds, then reports:
"x-create-frame-with-faces: Display localhost:10.0 can't be opened".

Re: CVS trunk emacsclient: X11 connection rejected

[Glenn Morris]

Glenn Morris wrote:

> If you wanted me to start an Emacs on host1 before `ssh host2', then
> it's unresponsive for a few seconds, then repors:
> "x-create-frame-with-faces: Display localhost:10.0 can't be opened".

Sorry, I'm confusing myself with too much ssh'ing. The actual error is:

"Connection lost to X server `localhost:10.0'"

and in the terminal I see: "X11 connection rejected because of wrong
authentication.".

Re: CVS trunk emacsclient: X11 connection rejected

[Stefan Monnier]

>>> I did try a test with an unset XAUTHORITY:
>> 
host1> XAUTHORITY= emacs -Q -f server-start &
host1> ssh host2
host2> ssh host1 emacsclient --no-wait $PWD/README
>> 
>>> and it didn't seem to help.

> OK, so the above definitely doesn't change anything, I still get "X11
> connection rejected".

> If instead I unset XAUTHORITY before starting Emacs, or set it to
> ~/.Xauthority, then `ssh host2' warns "No xauth data; using fake
> authentication data for X11 forwarding.".

If you do

   host1> XAUTHORITY= xterm

is an xterm created?
What does `xhost' say?

> emacs, etc. Now the emacsclient command (with no display option) shows
> the behaviour of popping up a new frame of the server Emacs showing
> scratch, and not visiting the specified file at all.

That's good: the separate frame is normal (it's because the
emacsclient uses display "localhost:10.0" which Emacs can't know is
the same as display ":0.0"), and the "2 frames but no file" problem is
"known" (you already reported it) and is unrelated to X11
connection problems.

>> What happens if you do
host2> ssh host1
host1> echo "$DISPLAY"

> Is that meant to be that way round? I should have used better names
> than "host1", "host2". :)

I meant just that: assuminh you already have a shell on host2 (probably
via ssh), that was meant to say: do "ssh host1" to log back onto the
local computer.  And in this new interactive shell use `echo "$DISPLAY"'
to get the display number chosen by ssh.  The interactive shell is also
used just to keep the connection open.

host1> ssh host2
host2> ssh host1 'echo $DISPLAY'   # localhost:10.0
host2> emacs -Q --eval '(make-frame-on-display "localhost:10.0")'
> then it works.

Huh?  Really?  How can it?  `localhost:10.0' proxy display should be
created by the `ssh host1' and destroyed as soon as `ssh
host1' terminates.  Maybe it's a side effect of the connection sharing
feature of "recent" OpenSSH?


        Stefan

Re: CVS trunk emacsclient: X11 connection rejected

[Glenn Morris]

Stefan Monnier wrote:

> If you do
>
>    host1> XAUTHORITY= xterm
>
> is an xterm created?

Yes.

> What does `xhost' say?

   access control enabled, only authorized clients can connect
   SI:localuser:gmorris

> host1> ssh host2
> host2> ssh host1 'echo $DISPLAY'   # localhost:10.0
> host2> emacs -Q --eval '(make-frame-on-display "localhost:10.0")'
>> then it works.
>
> Huh? Really? How can it? `localhost:10.0' proxy display should be
> created by the `ssh host1' and destroyed as soon as `ssh host1'
> terminates. Maybe it's a side effect of the connection sharing
> feature of "recent" OpenSSH?

I don't know. I freely admit it's possible I'm getting confused by all
this ssh'ing... The environment from which Emacs is launched above
also has DISPLAY = localhost:10.0.

Re: CVS trunk emacsclient: X11 connection rejected

[Stefan Monnier]

> What happens if you do

> host2> ssh host1
> host1> echo "$DISPLAY"

> and then use this DISPLAY (presumably somehting like "localhost:10"): go to
> your Emacs and type

>    M-: (make-frame-on-display "localhost:10") RET

The above things are meant to reproduce more or less what
`ssh host1 emacclient' does, so as to try and take out emacsclient from
the equation.  So yes: first start Emacs, then ssh into host2 from there
ssh back into host1 and then ask Emacs to connect to the pseudo-display
"localhost:10.0" that goes through the two ssh tunnels.


        Stefan

Re: CVS trunk emacsclient: X11 connection rejected

[Glenn Morris]

Stefan Monnier wrote:

> The above things are meant to reproduce more or less what `ssh host1
> emacclient' does, so as to try and take out emacsclient from the
> equation. So yes: first start Emacs, then ssh into host2 from there
> ssh back into host1 and then ask Emacs to connect to the
> pseudo-display "localhost:10.0" that goes through the two ssh
> tunnels.

It fails in the same way:

"X11 connection rejected because of wrong authentication." in the terminal,
and

"Connection lost to X server `localhost:10.0'" in x-create-frame.


So does:
host1> xterm -display 'localhost:10.0'


If you think this is just something funny to do with my local set-up,
or indeed just normal behaviour, we can stop investigating this. The
--display suggestion you made for emacsclient enables me to do what I
want.

Re: CVS trunk emacsclient: X11 connection rejected

[Stefan Monnier]

> If you think this is just something funny to do with my local set-up,
> or indeed just normal behaviour, we can stop investigating this.
> The --display suggestion you made for emacsclient enables me to do
> what I want.

The "DISPLAY=" trick is probably the closest to previous emacsclient
behavior, so maybe we should provide a flag for it.  Or at least accept
"--display ''".


        Stefan

Re: CVS trunk emacsclient: X11 connection rejected

[Jan Djärv]

Glenn Morris skrev:
> With Emacs 22, and two GNU/Linux hosts with a common (NFS)
> file-system, I can do this:
> 
>>From an X-session running on host1:
> 
> host1> emacs -Q -f server-start &
> host1> ssh host2
> host2> ssh host1 emacsclient --no-wait $PWD/README
> 
> which visits the README file in the Emacs running on host1. I often
> find this convenient, because I often ssh between various machines and
> want to have a single Emacs instance. (The "emacsclient" part is
> hidden inside an "emacs" wrapper script that Does The Right Thing
> according to the situation.)
> 
> If I try the same thing with the CVS trunk, then I get the following
> error when trying to run emacsclient:
> 
>   X11 connection rejected because of wrong authentication.

This is a ssh error message.  It usually means that forwarding is not working
and sometimes the X11UseLocalhost option to sshd fixes it.

I think in your case the first emacs you start has a different DISPLAY than
emacsclient and then the ~/.Xauthority does not match.  Maybe an ssh(d)
upgrade caused this problem?  Or as you indicate, the multitty stuff has
changed how Emacs uses DISPLAY:s.  IT can also be so simple as some of your
home directories can't be written to or ~/.Xauthority is not writable.

I guess you have to run sshd with -v (or .d <number>) to exactly see what is
going on.

	Jan D.

Re: CVS trunk emacsclient: X11 connection rejected

[Glenn Morris]

Jan Djärv wrote:

> This is a ssh error message. It usually means that forwarding is not
> working and sometimes the X11UseLocalhost option to sshd fixes it.
>
> I think in your case the first emacs you start has a different
> DISPLAY than emacsclient and then the ~/.Xauthority does not match.
> Maybe an ssh(d) upgrade caused this problem? Or as you indicate, the
> multitty stuff has changed how Emacs uses DISPLAY:s. IT can also be
> so simple as some of your home directories can't be written to or
> ~/.Xauthority is not writable.

I guess it wasn't clear: I've got both Emacs 22 and CVS trunk
installed. With 22 client/server, it works; with trunk it fails as
described. So it can't be anything like home directory permissions. It
can only be a ssh problem if it is one that has remained hidden until
the recent changes to emacsclient/server have somehow brought it to
light. I have no other problems with ssh X11 forwarding.