bug#5434: 23.1; Emacsclient fails with Rejected Authentication Over SSH
Joel J. Adamson
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the bug-gn...@gnu.org mailing list,
and to the gnu.emacs.bug news group.
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
Having started an Emacs session on <remote-host> (the machine that
generate this bug report), logging in via ssh and attempting to bring up
an Emacs frame using 'emacsclient -c' on the local display yields
,----
| *ERROR*: Display localhost:10.0 can't be opened
`----
From Emacs.
,----
| $ emacsclient -c
`----
immediately yields
,----
| X11 connection rejected because of wrong authentication.
`----
This completely disables X11 forwarding FOR EMACSCLIENT ONLY.
Gnome-terminal still works. Changing default xauth does not help.
Deleting ~/.Xauthority on localhost and remote-host does not affect the
problem.
Basically emacsclient doesn't work over ssh. Bummer!
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/23.1/etc/DEBUG for instructions.
In GNU Emacs 23.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.18.3)
of 2009-12-03 on x86-5.fedora.phx.redhat.com
Windowing system distributor `Fedora Project', version 11.0.10704000
configured using `configure '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xft' '--with-xpm' '--with-x-toolkit=gtk' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=none
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t
Major mode: Org-Agenda Week Grid
Minor modes in effect:
diff-auto-refine-mode: t
which-function-mode: t
show-paren-mode: t
savehist-mode: t
epa-global-mail-mode: t
display-time-mode: t
shell-dirtrack-mode: t
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
0 <help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <down-mouse-1> <mouse-1> N
o n - g o o g l e M-b M-c SPC D i s c u s s i o n SPC
B o a r d M-} C-n I SPC m a y SPC h a v e SPC m i s
s e d SPC s o m e t h i n g , SPC b u t SPC i t SPC
l o o k s SPC l i k e SPC I SPC c a n SPC o o n l y
SPC j o i n SPC t h e SPC f o r u m SPC b y SPC c r
e a t i n g SPC a SPC G o o g l e SPC a c c o u n t
. SPC SPC I S-SPC w o u l d SPC p r e f e r SPC t o
SPC t a k e SPC a a p M-D p a r t SPC i n SPC d s <backspace>
i s c u s s i o n s SPC w o u M-D w i t h o u t SPC
h a v i n g SPC a SPC g o o g l e M-b M-c SPC a c c
o u n t . SPC SPC I s SPC t h e r e SPC w a M-D a SPC
w a y SPC t o SPC d o SPC t h i s ? C-j C-j T h a n
k s , C-j C-j J o e l C-c C-c C-x 5 0 M-x r e p o r
t SPC e m a c s SPC SPC <return>
Recent messages:
Processing deletes and refiles for +mhe-index/sequence/unseen...done
No current message
Composing a message...
Type C-c C-c to send message, C-c ? for help
When done with this frame, type C-x 5 0
Spell-checking region using aspell with default dictionary...done
Spell-checking region using aspell with default dictionary...done
Saving file /home/joel/Mail/draft...
Wrote /home/joel/Mail/draft
Sending...backgrounded
--
Joel J. Adamson -- http://www.unc.edu/~adamsonj
Servedio Lab
University of North Carolina at Chapel Hill
CB #3280, Coker Hall
Chapel Hill, NC 27599-3280
Jan Djärv
I don't understand your setup.
Do you
1) start Emacs as a daemon on host A.
2) you then ssh in to host A and try to do emacsclient -c?
That won't work if you have ssh X forwarding on, which is what you seem to have.
The emacs daemon runs on display :0 (or something similar), and emacsclient
tries to open your forwarded display, localhost:10, which goes to the host you
came from. This can never work. Please clarify if I misunderstood.
Jan D.
Joel J. Adamson
Yes, I start an Emacs session, including (server-start), and then ssh in
to that machine using
$ ssh -CY me@myhost
and enter the emacsclient command. Is there something unconventional
about this? I'm running emacsclient remotely; I thought this was the
main reason emacsclient was created (and I've been using it this way for
two years).
> That won't work if you have ssh X forwarding on, which is what you
> seem to have.
It worked just fine until I started using Fedora on my server, and it
works from other servers: if I log in to a University server from the
same client and issue the same commands, with X forwarding and so on, I
get a new Emacs window on my local display.
> The emacs daemon runs on display :0 (or something similar), and
> emacsclient tries to open your forwarded display, localhost:10,
> which goes to the host you came from. This can never work.
Never? As I said, it worked until I switched the OS on my workstation,
and it works on other machines.
Should I try it without X forwarding? I must be as confused as you are
because as I said, this worked until my recent changes. Before I used
Slackware 13.0 with Emacs from CVS (my switch was two months ago).
Thanks,
Joel
Dan Nicolaescu
> Please write in English if possible, because the Emacs maintainers
> usually do not have translators to read other languages for them.
>
> Your bug report will be posted to the bug-gn...@gnu.org mailing list,
> and to the gnu.emacs.bug news group.
>
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
> Having started an Emacs session on <remote-host> (the machine that
> generate this bug report), logging in via ssh and attempting to bring up
> an Emacs frame using 'emacsclient -c' on the local display yields
>
> ,----
> | *ERROR*: Display localhost:10.0 can't be opened
> `----
>
> From Emacs.
>
> ,----
> | $ emacsclient -c
> `----
>
> immediately yields
>
> ,----
> | X11 connection rejected because of wrong authentication.
> `----
Does:
$ emacs
work at this point?
I use the scenario you describe every day, so it should work.
Try connecting with "ssv -v"
and see what message it prints when you try "emacsclient -c"
Jan D.
>>>>>> "Jan" == Jan Djärv<jan...@swipnet.se> writes:
>
> > Joel J. Adamson skrev 2010-01-20 17.21:
> >>
> >> maintainers usually do not have translators to read other
> >> languages for them.
> >>
> >> Your bug report will be posted to the bug-gn...@gnu.org
> >> mailing list, and to the gnu.emacs.bug news group.
> >>
> >> Please describe exactly what actions triggered the bug and the
> >> precise symptoms of the bug:
> >>
> >> Having started an Emacs session on<remote-host> (the machine that
> >> generate this bug report), logging in via ssh and attempting to
> >> bring up an Emacs frame using 'emacsclient -c' on the local
> >> display yields
> >>
> >> ,---- | *ERROR*: Display localhost:10.0 can't be opened `----
> >>
> >> From Emacs.
> >>
> >> ,---- | $ emacsclient -c `----
> >>
> >> immediately yields
> >>
> >> ,---- | X11 connection rejected because of wrong authentication.
> >> `----
> >>
Ok, I did not get what you tried to do.
You have an X permission problem, you server probably has set
ForwardX11Trusted to no in /etc/ssh/ssh_config, or the default is no.
Try setting it to yes.
If that doesn't work, you have to read up on xauth to propagate
permissions from your server to the client where emacs daemon runs.
Jan D.
Jan Djärv
> 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.
>
> As Dan suggested, I ran ssh -v, and this is what I got:
>
This is strange, there should be a lines like this:
debug1: Requesting X11 forwarding with authentication spoofing.
Anyway, one source for this problem is that the shell that runs emacs -daemon
has set XAUTHORITY in the environment to point to some other file.
That environment variable isn't set when you ssh in, so xauth writes to
~/.Xauthority
If this is the case, when you ssh in you must do:
% XAUTHORITY=... (the value it has in the emacs -daemon shell).
% export XAUTHORITY
% xauth remove unix:10
% xauth merge ~/.Xauthority
It might happen that you don't have unix:10, look at your $DISPLAY and replace
localhost with unix in the xauth remove line. 10 is where sshd starts, but if
several ssh sessions to the same host are ongoing, they will have different
DISPLAY:s.
Jan D.
> ,----
> | ezra: ~ > ssh -v joel@hostname
> | OpenSSH_5.2p1, OpenSSL 1.0.0-fips-beta4 10 Nov 2009
> | debug1: Reading configuration data /etc/ssh/ssh_config
> | debug1: Applying options for *
> | debug1: Connecting to 'name removed' port 22.
> | debug1: Connection established.
> | debug1: identity file /home/joel/.ssh/identity type -1
> | debug1: identity file /home/joel/.ssh/id_rsa type 1
> | debug1: identity file /home/joel/.ssh/id_dsa type -1
> | debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
> | debug1: match: OpenSSH_5.2 pat OpenSSH*
> | debug1: Enabling compatibility mode for protocol 2.0
> | debug1: Local version string SSH-2.0-OpenSSH_5.2
> | debug1: SSH2_MSG_KEXINIT sent
> | debug1: SSH2_MSG_KEXINIT received
> | debug1: kex: server->client aes128-ctr hmac-md5 none
> | debug1: kex: client->server aes128-ctr hmac-md5 none
> | debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> | debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> | debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> | debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> | debug1: Host '<name removed>' is known and matches the RSA host key.
> | debug1: Found key in /home/joel/.ssh/known_hosts:2
> | debug1: ssh_rsa_verify: signature correct
> | debug1: SSH2_MSG_NEWKEYS sent
> | debug1: expecting SSH2_MSG_NEWKEYS
> | debug1: SSH2_MSG_NEWKEYS received
> | debug1: SSH2_MSG_SERVICE_REQUEST sent
> | debug1: SSH2_MSG_SERVICE_ACCEPT received
> | debug1: Authentications that can continue: publickey,gssapi-with-mic,password
> | debug1: Next authentication method: gssapi-with-mic
> | debug1: Unspecified GSS failure. Minor code may provide more information
> | Credentials cache file '/tmp/krb5cc_500' not found
> |
> | debug1: Unspecified GSS failure. Minor code may provide more information
> | Credentials cache file '/tmp/krb5cc_500' not found
> |
> | debug1: Unspecified GSS failure. Minor code may provide more information
> |
> |
> | debug1: Next authentication method: publickey
> | debug1: Offering public key: /home/joel/.ssh/id_rsa
> | debug1: Server accepts key: pkalg ssh-rsa blen 277
> | debug1: Authentication succeeded (publickey).
> | debug1: channel 0: new [client-session]
> | debug1: Requesting no-more-...@openssh.com
> | debug1: Entering interactive session.
> | debug1: Sending environment.
> | debug1: Sending env XMODIFIERS = @im=none
> | debug1: Sending env LANG = en_US.UTF-8
> `----
>
> Thanks,
>
> Joel
Jan Djärv
Joel J. Adamson skrev 2010-01-26 16.52:
>>>>>> "Jan" == Jan Djärv<jan...@swipnet.se> writes:
>
> > Anyway, one source for this problem is that the shell that runs
> > emacs -daemon has set XAUTHORITY in the environment to point to
> > some other file. That environment variable isn't set when you ssh
> > in, so xauth writes to ~/.Xauthority
>
> I'm running GNOME on Fedora 12, so
> XAUTHORITY=/var/run/gdm/auth-for-joel...
>
> This seems to be GDM-related. I will try to figure out how to configure
> GDM for this.
>
> When I ssh in 'echo $XAUTHORITY' returns empty (i.e. if I'm not sitting
> at the desk with my main workstation I can't find XAUTHORITY). If I can
> run the commands you suggested, it works.
>
Good, we can close this.
Jan D.
PS. Don't remove ddebugs.gnu.org from To or CC.
DS.
Jan Djärv
Stefan Monnier
>> XAUTHORITY=/var/run/gdm/auth-for-joel...
That is often a problem, not just for Emacs. You may want to report
this is a bug (or at least misfeature) to Fedora. I use GDM under
Debian and don't see this, so it might be related to the distribution or
to the gdm.conf.
Stefan
Jan Djärv
I don't think it is the dist, it is the same in Ubuntu.
Jan D.
Joel J. Adamson
It may be the GNOME version. I will experiment, as I have Ubuntu Karmic
at home.
Joel
--
Joel J. Adamson
Servedio Lab
University of North Carolina at Chapel Hill
CB #3280, Coker Hall
Chapel Hill, NC 27599-3280
http://www.unc.edu/~adamsonj
FSF Member #8164