From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.17 i686)
Description of problem:
This used to work:
machine1 %> ssh machine2
machine2 %> su
machine2 #> xeyes
But now I get an error:
X connection to localhost:10.0 broken (explicit kill or server shutdown).
To me it seems that XAUTHORITY environment variable is not set
by su and therefore /root/.Xauthority file is used.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Log in from a remote machine
4. echo $XAUTHORITY
Actual Results: 2. xeyes works
4. XAUTHORITY : undefined variable
5. X connection to localhost:10.0 broken (explicit kill or server shutdown).
Expected Results: 4. /root/.xauthxxxxx
5. xeyes should work
$DISPLAY is set correctly to localhost:10.0 for both me and root.
root #> xauth -v list
xauth: creating new authority file /root/.Xauthority
Using authority file /root/.Xauthority
I'm running RedHat 7.1, 2.4.9-31. I had upgraded to OpenSSH_3.1p1 by
installing the RPMs, and this broke the X11 forwarding. I worked around
the problem by creating the file,
OPTIONS="-o 'X11UseLocalhost no'"
and then I ran
What Pam said: you need to set the "X11UseLocalhost" option to "no".
The problem is that lots of X11 programs will make very aggressive optimizations
about what constitutes a "local" (versus TCP/IP) X11 transport. A DISPLAY value
of ":10.0" always means "use local transport" (the /tmp/.X11-unix/X0 unix
socket). A DISPLAY value of "hostname:10.0" usually means "use TCP/IP", but
some X11 applications are too smart for their own good, and will optimize
"localhost:10.0" (or 127.0.0.1:10.0) to just ":0.0" and attempt to use local
transport. Such apps then fail, because when forwarding the X11 protocol, the
sshd on the remote machine doesn't listen on the /tmp/.X11-unix/X0 socket; it
only listens on the TCP port.
IMO, it's completely stupid that the OpenSSH developers added this "feature".
They did it because people were whining about the fact that when you forwarded
an X11 connection to a remote machine, sshd was listening on *:6010 (port 6010
on all interfaces). That meant that anyone who could reach TCP port 6010 on the
remote machine could connect to sshd's X11 forwarding listener and try to attack
the X server of the machine you connected from (by trying to guess the magic
cookie for sshd's forwarder).
The *correct* solution is to tell people not to forward X11 connections to
remote machines that don't firewall the X11 display port ranges, or are
Besides, even with the X11UseLocalhost "feature", people logged into the remote
machine can still try to attack your local X server through sshd listening on
the loopback. So this "feature" is doubly stupid.
A suggestion for Red Hat: put "X11UseLocalhost no" in the /etc/ssh/sshd_config
X11UseLocalhost is broken in that the DISPLAY=localhost:10.0 but the key in .Xauthority is for the display :10.0. Some X programs optimize away the localhost and
find the correct key, but pam_xauth does not. This is why su'ing doesn't work.
[jpdalbec@<client> jpdalbec]$ ssh -X <server>
Last login: Thu Jul 11 03:10:48 2002 from <client>
[jpdalbec@<server> jpdalbec]$ export DISPLAY=:10.0
[jpdalbec@<server> jpdalbec]$ su
[root@<server> jpdalbec]# xeyes
Error: Can't open display: :10.0
[root@<server> jpdalbec]# export DISPLAY=localhost:10.0
[root@<server> jpdalbec]# xeyes
(xeyes appears on the client)
It works fine with the current Fedora Core.