Bug 146061 - Remote gnome-terminal through ssh tunnel fails
Summary: Remote gnome-terminal through ssh tunnel fails
Keywords:
Status: CLOSED DUPLICATE of bug 134425
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-terminal
Version: 3
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-01-25 01:40 UTC by Eric Hopper
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-21 19:08:02 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Eric Hopper 2005-01-25 01:40:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5)
Gecko/20041110 Firefox/1.0

Description of problem:
Whenever I try to use ssh (or any other remote X method for that
matter) to start up a gnome-terminal (or several other gnome programs)
it always fails with a BadAtom error.


Version-Release number of selected component (if applicable):
gnome-terminal-2.7.3-1

How reproducible:
Always

Steps to Reproduce:
1.ssh -X <some host> gnome-terminal


Actual Results:
The program 'gnome-terminal' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAtom (invalid Atom parameter)'.
  (Details: serial 67 error_code 5 request_code 20 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error()
function.)


Expected Results:  I expect a nice gnome-terminal running on the
remote host to appear on my screen.

Additional info:

Comment 1 Eric Hopper 2005-01-25 01:44:09 UTC
ssh -X seems to work for 'dia'.  'gimp' made it through the 'upgrade
from 2.0 to 2.2' dialog, and now it consistently crashes.


Comment 2 Ray Strode [halfline] 2005-01-25 01:48:11 UTC
What happens if you use ssh -Y instead of ssh -X?

Comment 3 Eric Hopper 2005-01-25 01:50:22 UTC

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

Comment 4 Eric Hopper 2005-01-25 02:25:59 UTC
Can you point me at any good documentation describing the exact
difference between -X and -Y?  I'm just curious.

Comment 5 Ray Strode [halfline] 2005-01-25 17:20:32 UTC
Hi,

-X means that ssh will use untrusted auth cookies for it's connections
to the xserver. 

-Y means that ssh will use trusted auth cookies.

The xauth man page describes this:
               If the trusted option is used, clients that connect
using this authorization will have full run of the display, as usual.
 If untrusted is used, clients that connect using this  authorization
 will be considered untrusted and prevented from stealing            
  or tampering with data belonging to trusted clients.  See  the     
         SECURITY  extension  specification  for  full  details  on
the               restrictions imposed on untrusted  clients.   The 
default  is               untrusted.

If you have the package xorg-x11-doc installed, then you can find the
SECURITY extension specification in 

/usr/share/doc/xorg-x11-doc-*/Xext/security.PS.gz

Comment 6 Eric Hopper 2005-01-25 17:31:35 UTC
Thanks a whole bunch.  I spent about an hour googling last night and
while I was able to find the -Y option, I couldn't find any
explanations of what it did, just vague hints.

I'm going to add this to the main report so people who are hunting for
it are more likely to find the explanation.


Comment 7 Red Hat Bugzilla 2006-02-21 19:08:02 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.


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