3.1p1 breaks X11 forwarding
bob at proulx.com
Tue Mar 12 18:52:18 EST 2002
> : X11 connection rejected because of wrong authentication.
> what OS?
Homebrew GNU/Linux of my own compilation, Redhat 7.1 with my own
compile of ssh, HP-UX 10.20, HP-UX 11.0, HP-UX 11.11, I got caried
away and updated everything before I found the problem. As you can
see I don't think the OS is significant here. But in this particular
case I am using HP-UX as the sshd server. [As a trip down memory lane
one of the other apps that always crashes is piglet. But synchronize
also exhibits the problem.]
I don't think that is the problem. The xterm comes through fine back
to back with other failing commands. I am $DISPLAYing onto the local
machine. So localhost at 127.0.0.1:12.0 should be fine. Although I
have previously been seeing the local_ip_address:12.0.
ssh -X remotehost
xterm & # works
synchronize & # fails with wrong authentication message
piglet & # fails with wrong authentication message
xterm & # works
xclock & # fails
xterm & # works
This happens when using either Protocol 1 or Protocol 2. As you can
see I can run commands back to back in the same window and see one
work and one fail.
That is the same as the problem I am describing.
> echo $DISPLAY
> What I exptected is:
> rodenss at ginkgo:~$ echo $DISPLAY
This has a similar message and similar DISPLAY behavior and the
problem is almost certainly related.
> /usr/bin/X11/xterm uses R5 libs.
I am using color xterm-159 compiled by me moons ago and it has been in
solid use since then. I think I compiled it using the R6 libs. The
shipped xterm is ancient.
It is probably pertinent that I am using a recently compiled xterm
using later libraries than the xterm shipped with hpux. I am using
the shipped (or patched) X11 libs on a 10.20 machine to compile the
xterm as I did not compile the X11 libs. Other stock applications are
causing the crash but this one does not.
> try /usr/contrib/bin/X11/xterm
That one has a broken resize, no sigwinch capability, and I remove it
with prejudice whenever I install a new system so that it does not get
invoked by accident. It is a very frustrating version.
> :Secondly, in going back to 3.0.2p1 to try to work around this problem
> :I was able to crash ssh with the following error. I window killed a
> :forwarded xterm which was running a separate X11 program also
> :forwarded. The child tunneled X11 program appeared to hang and I
> :killed the application. This crashed the underlying ssh with this
> :Received disconnect from 184.108.40.206: 2: Received ieof for nonexistent channel 8.
> can you submit that (plus exact how-to-dup details) to
I don't think I can generate a recipe for someone else to recreate
this unless they have synchronize handy which I don't expect.
The details are that I am running the X11 client on my GNU/Linux
desktop. ssh-3.0.2p1 -X hpux to sshd-3.1p1. There start up 'xterm -e
synchronize'. The xterm comes up but the synchronize window never
does. Running tcpdump in another window shows no network activity.
After ten minutes kill the xterm with a window manager window pulldown
kill (FVWM2). The original ssh -X connection then dies with that
message. When I try 'xterm -e xclock' I never get the xclock window
and killing xterm does not generate a death of the ssh client.
More information about the openssh-unix-dev