|Summary:||Nasty ssh and X server IPV6 interaction|
|Product:||[Fedora] Fedora||Reporter:||Douglas Campbell <doug.campbell>|
|Component:||openssh||Assignee:||Tomas Mraz <tmraz>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-05-25 13:01:06 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Douglas Campbell 2005-01-08 00:07:34 UTC
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-08 00:12:33 UTC
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 11:05:02 UTC
Just to rule it out as a factor, does using ssh -Y change the error produced?
Comment 3 Douglas Campbell 2005-01-09 04:06:17 UTC
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 18:06:03 UTC
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-10 00:07:55 UTC
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 19:58:38 UTC
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 05:53:18 UTC
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 08:31:13 UTC
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 16:04:54 UTC
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 16:37:11 UTC
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 21:46:52 UTC
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 22:01:28 UTC
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 20:09:00 UTC
So Mr. Campbell which (if any) update helped to resolve the issue?
Comment 14 Tomas Mraz 2005-05-25 13:01:06 UTC
No response from reporter. As the problem disappeared on updated packages anyway I'm closing the bug.