Bug 144544 - Nasty ssh and X server IPV6 interaction
Nasty ssh and X server IPV6 interaction
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-07 19:07 EST by Douglas Campbell
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-25 09:01:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Douglas Campbell 2005-01-07 19:07:34 EST
Description of problem:

X server is unable to handle hostname "localhost" properly when used
as element of DISPLAY environment variable.


Version-Release number of selected component (if applicable):


How reproducible:

every time.

Steps to Reproduce:
1.  From an IPV4 system, ssh to a Fedora Core 3 system with both IPV4
and IPV6 enabled.

2.  Run any X application (e.g., xclock, xterm).
3.  Observe errors similar to those outlined in "actual results".
  
Actual results:

[zzzzz@mushu ~]$ xterm
_X11TransSocketINETConnect() can't get address for localhost:6010:
Name or service not known
xterm Xt error: Can't open display: localhost:10.0



Expected results:

xterm opens on remote host.


Additional info:

after login via ssh, DISPLAY is set to localhost:10.0

The problem appears to be that "localhost" is being resolved to an
IPV6 address, and the X server is then becoming confused about the
syntax of the result (I suspect the colons in the IPV6 address).  If I
modify DISPLAY to have the value "127.0.0.1:10.0", my X application
successfully opens on the remote host.
Comment 1 Douglas Campbell 2005-01-07 19:12:33 EST
Problem also occurs if you "setenv DISPLAY :10.0".  Results:

[daddy@mushu ~]$ setenv DISPLAY :10.0
[daddy@mushu ~]$ xclock
_X11TransSocketINETConnect() can't get address for localhost:6010:
Name or service not known
Error: Can't open display: :10.0
Comment 2 Sitsofe Wheeler 2005-01-08 06:05:02 EST
Just to rule it out as a factor, does using ssh -Y change the error produced?
Comment 3 Douglas Campbell 2005-01-08 23:06:17 EST
ssh -Y appears to work between two fedora core 3 machines. In that case, the
DISPLAY is also set to localhost:0.0, but everything works.  In fact, if -Y not
specified, X won't work at all.  

In the case of my complaint, I tried this between an RHEL3 system and an FC3
system. I was not able to connect with DISPLAY set to localhost:0.0, but was
when it was set to 127.0.0.1:0.0.  Will attempt using ssh -Y monday between the
RHEL3 machine and FC3 and report back results.
Comment 4 Sitsofe Wheeler 2005-01-09 13:06:03 EST
I don't think the ssh included with RHEL3 had the seperate trusted/untrusted X
options (it was always trusted). I was unaware the box being ssh'd from was not
an FC3 box...
Comment 5 Douglas Campbell 2005-01-09 19:07:55 EST
Just checked; you are correct -- ssh -Y won't work on RHEL3.  However, my home
RHEL3 system (up2date kernel 2.4.21-27.0.1.EL) with all up2date patches applied
appears to work when it connects to the same fedora core 3 machine (via eth0
rather than eth1).  The failing system at work is an original RHEL3 distribution
with no maintenance applied.
Comment 6 Mike A. Harris 2005-02-11 14:58:38 EST
If "ssh -Y" resolved the problem, then this is not a bug at all.  It
is the result of openssh changing how X11 forwarding is done by
default.  Please refer to the Fedora Core 3 release notes for
more information.
Comment 7 Douglas Campbell 2005-02-12 00:53:18 EST
I will examine the FC3 release notes and comment back tomorrow.  At
present, I still think there is an interoperablility issue between FC3
and RHEL3.  You guys have changed out a lot of X11 between the two,
and if this is what the future is for RHEL4, I think you are going to
get a lot of complaints from your customers who will run RHEL4 in a
mixed environment.  I'm just giving you the heads up here.
Comment 8 Tomas Mraz 2005-02-14 03:31:13 EST
This isn't a problem with the trusted/untrusted forwarding as he is
ssh-ing from RHEL3 machine to FC3 one not the other way. However I'm
not sure which package is the culprit here - if it's ssh or X11. 

If the updated RHEL3 works for you, could you try updating at least
the X11, openssh, kernel and glibc packages on the original system to
see if the problem disappears?
Comment 9 Douglas Campbell 2005-02-14 11:04:54 EST
Ah, I understand.  Mr. Harris thought I was going from the FC3 system
to RHEL3.  No, it is from RHEL3 to FC3. I did try to mine the FC3
release notes, and came up dry.

Mr. Mraz, in which order should I attempt the update?  And which
kernel packages are we discussing?
Comment 10 Tomas Mraz 2005-02-14 11:37:11 EST
I'd say start with openssh, then X, then glibc and kernel. You should
update to the latest available packages if possible.
Comment 11 Douglas Campbell 2005-02-14 16:46:52 EST
I don't know if this is important, but I just got an e-mail from
bugzilla telling me that I personally removed bbrook as the redhat
QAContact for this trouble report.  I didn't know I had that power,
nor do I believe that I did this.

I will perform the upgrades in the order specified on the unpatched
system as soon as possible and report the results here.  Cheers...
Comment 12 Mike A. Harris 2005-02-16 17:01:28 EST
Douglas:

Our bugzilla has a bug in it that causes the QA contact field
to be removed sometimes, however our bugzilla admins have not
yet isolated the problem.  If you experience this problem, it
might be useful to them if you could file a bug report against
our bugzilla component, indicating what fields you changed,
etc.

Hope this helps.
Comment 13 Tomas Mraz 2005-04-05 16:09:00 EDT
So Mr. Campbell which (if any) update helped to resolve the issue?
Comment 14 Tomas Mraz 2005-05-25 09:01:06 EDT
No response from reporter. As the problem disappeared on updated packages anyway
I'm closing the bug.

Note You need to log in before you can comment on or make changes to this bug.