Bug 505545 - ssh -Y fails from remote GDM session
Summary: ssh -Y fails from remote GDM session
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-xauth
Version: 20
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 759205 (view as bug list)
Depends On: 1018603
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-12 11:35 UTC by Michael Young
Modified: 2014-07-19 05:54 UTC (History)
12 users (show)

Fixed In Version: xorg-x11-xauth-1.0.9-1.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-09 02:31:12 UTC
Type: ---


Attachments (Terms of Use)
Patch to improve xauth to handle FamilyWild. (3.53 KB, patch)
2011-12-01 16:33 UTC, Dr. Tilmann Bubeck
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 43425 0 None None None Never
GNOME Bugzilla 681170 0 None None None 2012-08-03 22:22:07 UTC
Red Hat Bugzilla 759205 0 unspecified CLOSED xauth is unable to handle FamilyWild and therefore SSH unable to ForwardX11 with GDM/XDMCP 2021-02-22 00:41:40 UTC

Internal Links: 759205

Description Michael Young 2009-06-12 11:35:51 UTC
If I make a connection to a server GDM with XDMCP enabled (eg. via Xnest -query server :1 ) and use this session to ssh -Y to another server, I get the warning
Warning: No xauth data; using fake authentication data for X11 forwarding.
when connecting, and attempts to start an X application (eg. xclock) fail with the error
Invalid MIT-MAGIC-COOKIE-1 keyError: Can't open display: localhost:10.0
Back on the GDM session if I run xauth I get a line like
#ffff#3132392e3233342e322e313134#:1  MIT-MAGIC-COOKIE-1 33c9c88bbbf68a7290301845b5f9554c
and it seems ssh -Y doesn't understand that format (ssh -X doesn't have a problem). If I use xauth to add a line like
localhost:1 MIT-MAGIC-COOKIE-1 33c9c88bbbf68a7290301845b5f9554c
then ssh -Y starts working again.

Comment 1 Ray Strode [halfline] 2009-08-04 13:40:40 UTC
looks like the hostname is getting written out with garbage, not sure why off hand.  Will need to investigate.

Comment 2 Michael Young 2009-08-04 14:44:16 UTC
I had a look at gdm code and in daemon/gdm-display-access-file.c in the _get_auth_info_for_display subroutine (circa line 440) you have the code
        if (is_local) {
                char localhost[HOST_NAME_MAX + 1] = "";
                *family = FamilyLocal;
                if (gethostname (localhost, HOST_NAME_MAX) == 0) {
                        *address = g_strdup (localhost);
                } else {
                        *address = g_strdup ("localhost");
                }
        } else {
                *family = FamilyWild;
                gdm_display_get_remote_hostname (display, address, NULL);
        }
the entry seems to be consistent with the wildcard format, but it seems ssh -Y doesn't like it. However there is probably no reason to use the wildcard format anyway.

Comment 3 Michael Young 2009-08-22 21:41:41 UTC
The patch below might be a possible approach to fix the problem from the gdm end. It works for me in some circumstances though won't for IPV6 or if there is a 0 in an IPV4 address (such as 127.0.0.1 which is the circumstance where it doesn't work for me).

--- gdm-2.26.1/daemon/gdm-display-access-file.c.orig	2009-03-26 19:15:09.0000
00000 +0000
+++ gdm-2.26.1/daemon/gdm-display-access-file.c	2009-08-21 11:35:01.000000000 +0
100
@@ -37,6 +37,10 @@
 #include <glib/gi18n.h>
 
 #include <X11/Xauth.h>
+#include <X11/X.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
 
 #include "gdm-display-access-file.h"
 #include "gdm-common.h"
@@ -446,8 +447,12 @@
                         *address = g_strdup ("localhost");
                 }
         } else {
-                *family = FamilyWild;
-                gdm_display_get_remote_hostname (display, address, NULL);
+		in_addr_t inp;
+		gdm_display_get_remote_hostname (display, address, NULL);
+		inp=inet_addr(*address);
+		g_debug ("_get_auth_info_for_display: IP is %d\n", inp);
+		*address = g_strndup(&inp, 4);
+                *family = FamilyInternet;
         }
         *address_length = strlen (*address);

Comment 4 Bug Zapper 2010-04-27 14:49:00 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 Michael Young 2010-05-12 12:20:06 UTC
This is still an issue in Fedora 12 and 13.

Comment 6 Bug Zapper 2010-11-04 11:08:00 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Michael Young 2010-11-04 12:34:52 UTC
This is still a problem in Fedora 14.

Comment 8 Fedora Admin XMLRPC Client 2011-06-21 15:33:18 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 9 Fedora Admin XMLRPC Client 2011-06-21 15:36:21 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Fedora Admin XMLRPC Client 2011-06-21 15:37:49 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 11 Fedora Admin XMLRPC Client 2011-06-21 15:41:00 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 12 Fedora Admin XMLRPC Client 2011-06-21 15:50:30 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 13 Fedora Admin XMLRPC Client 2011-06-21 15:53:04 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 14 Fedora Admin XMLRPC Client 2011-06-21 15:55:32 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 15 Fedora Admin XMLRPC Client 2011-06-21 15:56:45 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 16 Dr. Tilmann Bubeck 2011-11-30 15:56:03 UTC
This is still an issue in Fedora 16.

I also came across that bug and before finding this bugzilla entry, I did also find out GDM to be the cause and also the above line, which is still there for GDM 3.2.1

Comment 17 Dr. Tilmann Bubeck 2011-12-01 16:04:02 UTC
After further investigation I found out, that the problem is IMHO not GDM but xauth.

The following happens:

1. GDM receives XDMCP request and creates a MIT-MAGIC-COOKIE-1 with FamilyWild.
2. This is stored in the users XAUTHORITY file.
3. If you use "xauth list" you will see the above entry. However, xauth is not
   able to deal with FamilyWild so it lists the entry as a unknown type.
   This is marked by starting the line with "#" and showing everything in hex.
   Here is an example:

   #ffff#31302e312e312e323030#:0  MIT-MAGIC-COOKIE-1 7f2ae3c1....9d943101

   This is problem #1.

4. If you use ssh to log into another computer, it will execute this before
   connecting: "xauth list $DISPLAY". In my case "DISPLAY=10.1.1.200:0".
   Because xauth does not know FamilyWild it will not match the above entry
   and will therefore print nothing. This will lead to the error message of ssh:
   "Warning: No xauth data; using fake authentication data for X11 forwarding."
   and X11 forwarding will not work.

   This problem #2 and related to problem #1.

There are 3 solutions to this problem:

A. Change from GDM to KDM which uses FamilyInternet instead of FamilyWild.

B. Patch GDM to use FamilyInternet instead of FamilyWild. This is known to
   xauth and will work. This is suggested above.

C. Improve xauth so that it will be able to deal with FamilyWild.

IMHO solution C is the best, because it will improve the situation in general instead of working around a problem in xauth.

I developed a patch based upon the current GIT of xauth. This patch improves xauth to handle FamilyWild. This patch is also submitted upstreams. I verified everything and the patch solves the problem without patching GDM.

Feel free to include this patch into Fedora if upstream is slow or unwilling to include.

Comment 18 Dr. Tilmann Bubeck 2011-12-01 16:33:53 UTC
Created attachment 539277 [details]
Patch to improve xauth to handle FamilyWild.

Comment 19 Wander Boessenkool 2012-08-03 17:04:03 UTC
I can confirm that this patch (comment 18, Till Bubeck) works on RHEL6.3.
Without this patch xauth and an Xvnc server with XDMCP started from xinetd do not play nice together when using pam_xauth.so, with this patch everything works like a charm.

Comment 20 Ray Strode [halfline] 2012-08-03 22:13:46 UTC
Thanks, Till. I just noticed this bug go by, moving to xorg-x11-xauth. I'll commit Michael's patch upstream in GDM so we get the best of both worlds.

Comment 21 Ray Strode [halfline] 2012-08-03 22:18:40 UTC
Hmm actually that patch will need a bit of work, let me file upstream for now so I don't forget about it.

Comment 22 Dr. Tilmann Bubeck 2012-08-05 13:15:45 UTC
You don't need both patches. Why?

The main problem is, that xauth is unable to deal with the (specified) "FamilyWild" and xauth is used by SSH to transfer x11 authorization to the remote host.

Michael's patch from comment #3 changes GDM to use FamilyInternet instead of FamilyWild.

My patch fixes xauth to be able to deal with FamilyWild.

I would prefer fixing xauth instead of working around that missing functionality from xauth. So I suggest applying my patch against xauth and drop the patch from Michael, if my patch got applied.

Comment 23 Ray Strode [halfline] 2012-08-06 19:28:15 UTC
To be clear, I'm saying:

1) It makes a ton of sense to fix xauth upstream and use it in fedora
2) In upstream GDM it makes sense to work with unfixed xauth too for wider compatibility.

Comment 24 Fedora End Of Life 2013-04-03 20:19:19 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 25 Dr. Tilmann Bubeck 2013-10-11 19:22:04 UTC
xauth-1.0.8 has been released upstreams (not yet packaged for Fedora), which fixes this bug.

Comment 26 Hans de Goede 2014-07-03 14:13:47 UTC
*** Bug 759205 has been marked as a duplicate of this bug. ***

Comment 27 Hans de Goede 2014-07-03 14:28:07 UTC
Hi All,

Thanks for are your patience on this, and for making sure a fix was done upstream.

An update to 1.0.9 is on its way to updates-testing for F-19+.

Regards,

Hans

Comment 28 Fedora Update System 2014-07-03 20:29:22 UTC
xorg-x11-xauth-1.0.9-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/xorg-x11-xauth-1.0.9-1.fc20

Comment 29 Fedora Update System 2014-07-03 20:32:57 UTC
xorg-x11-xauth-1.0.9-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/xorg-x11-xauth-1.0.9-1.fc19

Comment 30 Fedora Update System 2014-07-04 12:29:39 UTC
Package xorg-x11-xauth-1.0.9-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-xauth-1.0.9-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-8077/xorg-x11-xauth-1.0.9-1.fc20
then log in and leave karma (feedback).

Comment 31 Fedora Update System 2014-07-09 02:31:12 UTC
xorg-x11-xauth-1.0.9-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 32 Fedora Update System 2014-07-19 05:54:57 UTC
xorg-x11-xauth-1.0.9-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


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