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
will look into this
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
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.
Created attachment 132 [details] fix for autoconf 2.53 PATH problems
Could someone with autoconf 2.53 test attachment 132 [details] and see if it fixes the xauth problem.
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