Bug 338

Summary: X11 forwarding no longer works after upgrading from 2.9.9p2 to 3.4p1
Product: Portable OpenSSH Reporter: John R. Jackson <jrj>
Component: sshAssignee: OpenSSH Bugzilla mailing list <openssh-bugs>
Status: CLOSED FIXED    
Severity: normal    
Priority: P2    
Version: -current   
Hardware: SPARC   
OS: Solaris   
URL: ftp://gandalf.cc.purdue.edu/pub/ssh/ssh-X11-bug.tgz
Attachments:
Description Flags
fix for autoconf 2.53 PATH problems none

Description John R. Jackson 2002-07-06 04:20:45 AEST 
X11 forwarding no longer works after upgrading from 2.9.9p2 to 3.4p1.
When a client tries to connect it reports:

  Xlib: connection to "localhost:20.0" refused by server
  Xlib: Invalid MIT-MAGIC-COOKIE-1 key
  Error: Can't open display: localhost:20.0

Environment is Solaris 2.6 on both sides (ssh and sshd).

This worked just fine before the upgrade (with 2.9.9p2 on both sides).
I have further debugged it to being related to the 3.4p1 client side.
If I connect to either a 2.9.9p2 or 3.4p1 server with a 2.9.9p2 client,
I can start an X11 client.  If I connect to either server with a 3.4p1
client, it fails.

I tried both settings for X11UseLocalhost and can see the change to the
DISPLAY environment variable (so I know the X11UseLocalhost change was
taking place), but it made no difference to the problem.

I do not normally have a $HOME/.ssh/rc file.  I tried using the example
in the sshd man page, but that also had no effect.

I do not have a $HOME/.ssh/environment or /etc/ssh/sshrc file.

The debugging files, and build output, indicate xauth was found and is
being run.

As far as I recall, I only made two other changes at the time 3.4p1
was installed.  One was to put "Protocol 2" in sshd_config to disable
protocol version 1.  The other was to comment out some "UseRSH" lines in
my own $HOME/.ssh/config file since that no longer appears to be supported
(which is very unfortunate -- but that's a different matter).

The following file:

  ftp://gandalf.cc.purdue.edu/pub/ssh/ssh-X11-bug.tgz

contains copies of my config files, the build environment output, and
log files from my tests.

The test involved two machines.  Gandalf is a X11 workstation, i.e. it
has the display.  Fortress is another Solaris machine where I wanted to
start an client (xclock) and have it show up on the gandalf display.  So
the test, from gandalf, was:

  ssh fortress /usr/openwin/bin/xclock

Files named "client.*" are from the ssh side (gandalf).  Files named
"server.*" are from the sshd side (fortress).  Files named "*ssh-2*"
are using the 2.9.9p2 ssh, while those named "*ssh-3*" are using 3.4p1.
Files named "*sshd-2*" are using the 2.9.9p2 sshd, while those named
"*sshd-3*" are using 3.4p1.  All files are with "-v -v -v" and "-d -d -d".

John R. Jackson, Technical Software Specialist, jrj@purdue.edu
Comment 1 Kevin Steves 2002-07-07 04:00:49 AEST 
will look into this
Comment 2 Anders Nordby 2002-07-11 02:49:49 AEST 
Please try:

Add in sshd_config:

XAuthLocation /usr/openwin/bin/xauth

And in ssh_config:

Host *
   ForwardX11 yes
   ForwardAgent yes
   XAuthLocation /usr/openwin/bin/xauth
Comment 3 John R. Jackson 2002-07-11 05:50:24 AEST 
I figured out the problem.

The real culprit is, of all things, the version of bash that Sun now
releases.  The ./configure script tries to find a "good" shell to use.
On one of my machines (2.6) I had stupidly created a /bin/bash symlink
and it found that ahead of /bin/ksh.  On one of my Solaris 8 machines it
found the Sun version.  On all the others I had forced ./configure to use
/bin/ksh or it found it first on its own.  Those mismatches, of course,
led to all sorts of confusion as it appeared to me xauth was running OK.

In either case, bash is not capable of finding xauth properly with the
code that's in ./configure.  I added some debugging code and it does
something like this:

  Looking for /bin/xauth
  Looking for /usr/bin/xauth
  Looking for /usr/local/bin/xauth
  ...
  Looking for /usr/openwin/bin:/bin:/usr/bin:/usr/local/bin:.../xauth

It's clearly having trouble breaking $PATH apart, and, as luck would
have it, the problem is with the last element, which is where it puts
/usr/openwin/bin to look for xauth.  Sigh.

Bash was also was causing me other problems, which is why on most of my
machines I put "CONFIG_SHELL=/bin/ksh" in the ./configure environment.
Had I remembered to do that everyplace, I wouldn't have gone down this
twisty path.

The other two solutions to this (--with-xauth and XAuthLocation) should
both work, but only fix the xauth discovery issue.  I'd be real suspicious
of other things bash was messing up, though.

I tried to add some code to ssh.c to detect when xauth was missing,
which might have speeded up diagnosing this, but it got more complicated
than I wanted to spend time on.

You don't appear to have a text file documenting OS specific issues, but I
suggest a note someplace warning Solaris builders to stay away from bash.
Comment 4 Tim Rice 2002-07-17 14:44:07 AEST 
Created attachment 132 [details]
fix for autoconf 2.53 PATH problems
Comment 5 Tim Rice 2002-07-17 14:45:59 AEST 
Could someone with autoconf 2.53 test attachment 132 [details] and see
if it fixes the xauth problem.
Comment 6 John R. Jackson 2002-07-20 03:21:17 AEST 
I've verified the suggested patch in the 07/17/02 attachment takes care of the
problem.

John R. Jackson, Technical Software Specialist, jrj@purdue.edu