Bug 141894 - Remote X programs don't run
Summary: Remote X programs don't run
Keywords:
Status: CLOSED DUPLICATE of bug 137685
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: 3
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-12-04 20:49 UTC by Nigel Horne
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-01-31 20:40:21 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Nigel Horne 2004-12-04 20:49:18 UTC
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 08:58:36 UTC
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 14:19:52 UTC
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 14:23:34 UTC
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 14:24:49 UTC
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 18:00:29 UTC
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-07 01:23:41 UTC
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 09:13:31 UTC
Tks. 

Comment 8 Tomas Mraz 2005-01-31 20:39:40 UTC

*** This bug has been marked as a duplicate of 137685 ***


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