*** Bug 125698 has been marked as a duplicate of this bug. ***

According to bug 125698 this bug also affects other programs like
kuickshow and redhat-config-users, which could be expected if this is
a general openssh issue.

What happens if you try '-Y' instead of '-X'? (This is only applicable
to FC3t1 and FC-devel, NOT FC2.)

Things seem to be fine when using '-Y' (no crashes anymore).

I have never used -X nor -Y options of SSH and all has worked just
fine, until now.
What parameters is SSH using if to use plain "ssh host"?

If you connect to a remote system running openssh-3.8p1, run emacs in
X11 mode and try to select some text with the mouse => emacs will
crash, always. 


This can be fixed by adding to ~/.ssh/config (or /etc/ssh/ssh_config)

ForwardX11Trusted yes

See http://www.openssh.com/faq.html#3.13

A few comments:

If bug 125698 happens with Fedora Core 2, then it is *not* a dupe of
this bug.

This bug is filed against openssh, but strictly speaking, it's
probably not an OpenSSH bug. IIRC there are changes planned for a
later FC 3 test release which will add an SELinux-like security
infrastructure to xorg-x11, thereby fixing this bug. (I'll find the
relevant mailing list post later -- hopefully later today -- and I'll
add a comment here with the URL for that message.)

I can confirm that this behaviour is present on Fedora Core 2.

If I open up a ssh connecting from cygwin/windows on one pc towards
my linux machine using the "-X" option to ssh then mc craches when
pressing Ctrl-W and synaptic synaptics crashes when trying to select
a menu. If running ssh with "-Y" then the programs work without problems.

On linux:
    mc-4.6.0-15
    openssh-3.6.1p2-34
    xorg-x11-6.7.0-5
    synaptic-0.48.2-2.1.fc2.dag

On cygwin:
    OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004

Oh, wait... if bug 125698 happens with FC2 as the *server*, and
OpenSSH 3.8.1p1 on some other machine as the *client*, then it may be
a dupe of this bug, maybe.

In any case, the last paragraph of (my) comment #7 to this bug still
stands (this is a longstanding problem with the X security extension,
and/or X widget libraries which blindly assume the extension does not
exist -- hopefully a future FC 3 test release will fix this).

I am trying to make a remote connection to my racked server to install
Oracle. Oracle only uses a gui installer so i need X to work remotely
from my laptop at home running through a router and cable service. I
have done everything mentioned in the bug report and i am using the
latest devel packages for both the server and my laptop but when no
success. I am able to launch the installer on the server but when i
try to click the buttoned presented on the installer screen they do
not click. Any ideas?

Most of the X applications in our distribution are not going to
work OK with X security restrictions on.

We could probably make things a lot better with a few small patches
to GTK+, but 

 - Many applications will still have random X error crashes.

 - Things that the user expects to work (e.g. cut-and-paste,
   drag-and-drop) are likely not going to work.

 - It will take quite a while for these fixes to propagate
   to machines being ssh-ed onto.

If we ship with X forwarding on by default, we should ship with
it with the effect of -Y not -X. Subjecting users to crashes with 
the default configuration doesn't make sense to me.

As noted in comments 6 and 8, X11 forwarding in OpenSSH 3.8 and later
no longer defaults to using a trusted key for forwarded connections
(see http://www.openssh.com/faq.html#3.13 for details).  To forward
X11 using a trusted key, you must now use the -Y flag.

Packages of 3.8.1p1-1 and later no longer modify the upstream defaults
to request X11 forwarding by default (the server still permits it, but
the client must specifically request it), so "ssh" must be invoked
with either -X or -Y in order to forward X11 connections over the SSH
connection.

Perhaps mc could output a better error message in this failure case,
but otherwise this is not really a bug in openssh nor mc.  Will let
the mc maintainer decide if he wants to output a better error message,
or NOTABUG.

Using either -x or -Y will work, just not -X.  The -x flag explicitly
disables X11 forwarding, causing the DISPLAY variable to be unset.  In
this case, mc doesn't attempt to be mouse-aware.  With the -Y flag, mc
attempts to be mouse-aware, as before, but it doesn't run into any of
the problems which an untrusted client would run into.

Enrico,

the message displayed is caused by _XDefaultError() func in
/lib/X11/XlibInt.c in xorg. The workaround could be adding a new error
handler in a similar way like Leonard did to make mc displaying
something nicer than is seen from the screenshot you attached to bug
125698. Even with installed packages you've noticed I had problems to
reproduce the problem. For now I'll close this as NOTABUG and will be
watching 125698.

Jindrich