Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Remote X programs don't run|
|Product:||[Fedora] Fedora||Reporter:||Nigel Horne <njh>|
|Component:||openssh||Assignee:||Tomas Mraz <tmraz>|
|Status:||CLOSED DUPLICATE||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-01-31 15:40:21 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Nigel Horne 2004-12-04 15:49:18 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.2) Gecko/20040816 Description of problem: Ever since changing from FC2 to FC3, remote X programs have failed to start. Version-Release number of selected component (if applicable): xorg-x11-6.8.1-12.FC3.21 How reproducible: Always Steps to Reproduce: 1. Run xhost +<server-name> on your workstation 2. Run ssh X to a server 3. Login 4. Attempt to start any X program with DISPLAY set to the workstation Actual Results: The program will not run in GUI mode. Expected Results: The program should start a new X window on the local workstation containing the GUI of the remote program. Additional info: I have countless examples since no GUI programs fire correctly on FC3. Here is one example: [njh@ws njh]$ ssh -X njh njh@njh's password: Last login: Sat Dec 4 20:20:16 2004 from mac.bandsman.co.uk _X11TransSocketINETConnect() can't get address for localhost:6010: Name or service not known xhost: unable to open display "localhost:10.0" [njh@njh ~]$ gvim _X11TransSocketINETConnect() can't get address for localhost:6010: Name or service not known E233: cannot open display_X11TransSocketINETConnect() can't get address for localhost:6010: Name or service not known Hit ENTER or type command to continue
Comment 1 Sitsofe Wheeler 2004-12-06 03:58:36 EST
Do the programs work with ssh -Y? If so this could be a dup of bug #141515 (which looks like a dup of bug #134425)
Comment 2 Mike A. Harris 2004-12-06 09:19:52 EST
The X server TCP transport is disabled by default for many OS releases now for security reasons. It's been like this for a very long time now. The best way to run remote applications is via "ssh -Y". If you require remote TCP such as for XDMCP sessions or other reasons, you must reconfigure the system to permit remote TCP connectivity. The Fedora Core mailing lists may be useful if you require help reconfiguring your system to permit X over remote TCP. Setting status to "NOTABUG"
Comment 3 Mike A. Harris 2004-12-06 09:23:34 EST
Some additional information, as I may have slightly misread your initial report. You mention you're using ssh for remote X apps, but also using "xhost". "xhost" is very insecure, and is not required at all for running remote X apps over ssh. "xhost" is used for running remote apps over telnet, which is insecure and should be discouraged. The Fedora Core 3 release notes contain additional documentation on changes in the openssh software, which seem to be the problem you are having, rather than my initial assessment.
Comment 4 Mike A. Harris 2004-12-06 09:24:49 EST
Reassigning to openssh component for consideration of changing the default ssh options to work out of the box, so users don't have to reconfigure their systems to run remote X apps over ssh X11 forwarding.
Comment 5 Nigel Horne 2004-12-06 13:00:29 EST
Yes, that seems better, thanks. You say "It's been like this for a very long time now.", I suppose it depends on how you define 'very long', but FC2 was OK and I wouldn't say that was very long ago.
Comment 6 Mike A. Harris 2004-12-06 20:23:41 EST
Actually, it depends on what you define "it" as. As such, I'll clarify what I said in order to make it less ambiguous. "The X server TCP transport is disabled by default for many OS releases now for security reasons. It's been like this for a very long time now." In the above paragraph, the "It's" in the second sentence, is refering to how long it has been that we have disabled TCP in the X server by default. It has indeed been a very long time. I do not remember exactly when it was, but Red Hat Linux 7.1 or possibly even earlier is a rough guess. There was an OS release or two in which gdm by default invoked the X server without disabling TCP by default. That bug was fixed in a later gdm update. Bugs aside however, TCP has been disabled by default for numerous OS releases. > but FC2 was OK and I wouldn't say that was very long ago. It depends on which of the two completely different problems I described above that you're refering to. If you're refering to TCP being disabled by default, then it was indeed a very long time ago, as mentioned in my last paragraph, however if you're refering to "ssh -X" working out of the box as expected, then indeed this is a change in behaviour between FC2 and FC3. The upstream openssh project has changed what "ssh -X" does, so it no longer does what people are used to. To get the old behaviour, you must run "ssh -Y", as our release notes say. This is indeed new behaviour in FC3 caused by an upstream openssh project change. Again though, my claim above about "a very long time" was not about the openssh change, but rather the TCP one. Hope this clarifies any confusion from the above. Thanks.
Comment 7 Nigel Horne 2004-12-07 04:13:31 EST