Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 05 Feb 2001 01:00:04 -0500
From:      Bob Johnson <bobj@ufl.edu>
To:        freebsd-stable@freebsd.org
Subject:   Is X11 forwarding broken in recent -STABLE (OpenSSH 2.3.0)?
Message-ID:  <3A7E4164.F8FDDAF@ufl.edu>

next in thread | raw e-mail | index | archive | help
I have three systems:
system1:   FreeBSD 4.2-RELEASE (OpenSSH 2.2.0)
bobj:      FreeBSD 4.2-STABLE updated 2001-02-04 (OpenSSH 2.3.0)
Everex:    FreeBSD 4.2-20010128-STABLE snapshot (OpenSSH 2.3.0)

From either STABLE system I can forward X11 from the RELEASE 
system with SSH, e.g.  "ssh -X system1 xclock"  works just fine.

Neither of the STABLE systems can forward X11 to each other 
via SSH, or to themselves.  It appears that sshd in recent 
-STABLE is not doing X11 forwarding.  Connections abort (after 
a fair amount of network activity) with error messages such 
as 
  _X11TransSocketINETConnect: Can't connect: errno = 60
  Error: Can't open display: Everex.xxxxxyyyz.org:10.0

The configuration files on the three systems are the same 
except for the deprecated connection rate throttling statement, 
and I have tried explicitly enabling X11 forwarding, without 
success.  I have tried connecting with an interactive session 
(i.e. "ssh -X system1") and looked at the environment variables, 
the same variables seem to be set up for both working and 
non working situations.  In particular, XAUTHORITY and SSH_TTY 
are set up.  There do not appear to be SSH_AUTH_SOCK or 
SSH_CLIENT environment variables any either case.

I searched the mailing lists and found one claim that OpenSSH 
has this bug in early ver. 2.3.0 patchlevels, and that it can 
be fixed by downloading and installing a more recent version 
directly from OpenSSH.  I went to the OpenSSH web site and 
couldn't confirm that such a bug exists, so I haven't yet 
attempted this.

So, my first question is "does X11 forwarding work properly 
with the OpenSSH 2.3.0 sshd from recent -STABLE"?  If it 
does, I'll start gathering config files and debug logs in 
case that will help someone help me...

One last clue is that the two non-working systems are on 
a private-IP subnet with an invented (but unique) domain 
name and their own nameserver.  If I need to I can move 
them to a subnet where they will have real names to see 
what happens.

Thanks,

- Bob


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A7E4164.F8FDDAF>