3.1p1 breaks X11 forwarding

[Pekka Savola]

Hello all,

Just as heads-up: On all-Linux systems, the necessity X11UseLocalhost=no
(in some, more complex scenarios)  also depends on whether IPv6 is enabled
in sshd or not.

I've yet to corner down what's causing this but I've seen a few cases 
that:

(assuming X11UseLocalhost yes is the default)
WORKS: sshd -4
WORKS: sshd -o 'X11UseLocalhost no'
DOESN'T WORK: sshd
 
(the application used was xterm).

If this doesn't happen without Linux, it may be due to the Linux
mapped-address implementation.

I believe this will also have to do with the fact whether IPv6 has been 
enabled in X11 along the path.

On Tue, 12 Mar 2002, Bob Proulx wrote:

> > :  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.]
> 
> >      X11UseLocalhost
> 
> 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.
> 
> > also:
> > http://bugzilla.mindrot.org/show_bug.cgi?id=150
> 
> That is the same as the problem I am describing.
> 
> > echo $DISPLAY
> > localhost:13.0
> > What I exptected is:
> > rodenss at ginkgo:~$ echo $DISPLAY
> > 10.100.53.39:13.0
> 
> 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
> > :message.
> > :
> > :Received disconnect from 216.17.153.58: 2: Received ieof for nonexistent channel 8.
> > 
> > can you submit that (plus exact how-to-dup details) to
> > http://bugzilla.mindrot.org/
> 
> 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.
> http://www.crosswind.com/sitemap.htm#sync.
> 
> 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.
> 
> Bob
> 
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords