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): How reproducible: Always Steps to Reproduce: 1. Log in from a remote machine 2. xeyes 3. su 4. echo $XAUTHORITY 5. xeyes 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 Additional info: $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 openssh-askpass-3.1p1-2 openssh-askpass-gnome-3.1p1-2 openssh-server-3.1p1-2 openssh-3.1p1-2 openssh-clients-3.1p1-2 sh-utils-2.0.11-5 pam-0.75-19
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, /etc/sysconfig/sshd having contents, OPTIONS="-o 'X11UseLocalhost no'" and then I ran /etc/rc.d/init.d/sshd restart ---Pam
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 otherwise insecure. 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 by default.
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. Example: [jpdalbec@<client> jpdalbec]$ ssh -X <server> jpdalbec@<server>'s password: Last login: Thu Jul 11 03:10:48 2002 from <client> [jpdalbec@<server> jpdalbec]$ export DISPLAY=:10.0 [jpdalbec@<server> jpdalbec]$ su Password: [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.