Bug 863350 - ssh fails GSSAPI/Kerberos authentication when DNS reverse mapping not working
ssh fails GSSAPI/Kerberos authentication when DNS reverse mapping not working
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
18
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Petr Lautrbach
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-05 04:05 EDT by Marko Myllynen
Modified: 2012-12-20 11:24 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-20 11:24:25 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Marko Myllynen 2012-10-05 04:05:21 EDT
Description of problem:
When DNS reverse mapping for a server on the client side doesn't work ssh login fails with:

$ ssh -vvv server.example.com
...
debug3: Trying to reverse map address 192.168.122.1.
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address

...

This happens regardless rdsn = false in krb5.conf or GSSAPITrustDns / VerifyHostKeyDNS being yes or no for ssh(1). After setting up DNS reverse mapping on the client side to work properly GSSAPI/Kerberos authentication works as expected.

Version-Release number of selected component (if applicable):
openssh-6.1p1-1.fc18.x86_64
Comment 1 Marko Myllynen 2012-10-29 04:31:35 EDT
Petr, did you happen to have any time to look at this yet, can you reproduce this? Would be great to have this fixed before F18 especially now that FreeIPA 3 is in Fedora and more and more people are starting to use Kerberos.

Thanks.
Comment 2 Petr Lautrbach 2012-10-29 12:58:50 EDT
I'm finally able to reproduce this. It's probably due to openssh-5.8p1-gssapi-canohost.patch:

 	else if (options.gss_trust_dns)
 		gss_host = get_canonical_hostname(1);
-	else
-		gss_host = authctxt->host;
+	else {
+		gss_host = get_canonical_hostname(1);
+		if ( strcmp( gss_host, "UNKNOWN" )  == 0 )
+			gss_host = authctxt->host;
+	}


Regardless of the options.gss_trust_dns value, it calls get_canonical_hostname(use_dns = 1)
Comment 3 Petr Lautrbach 2012-10-29 13:32:18 EDT
http://koji.fedoraproject.org/koji/taskinfo?taskID=4636337

A temporary build without openssh-5.8p1-gssapi-canohost.patch for testing. However, the change of openssh-5.8p1-gssapi-canohost.patch will be needed instead of dropping it in a regular update.
Comment 4 Simo Sorce 2012-10-29 14:24:05 EDT
Petr I see no rationale for that patch, nor a comment, can  you point me at the discussion/description of why that patch is there and was deemed needed ?
Comment 5 Petr Lautrbach 2012-10-30 03:15:08 EDT
I haven't found any discussion too. It's probably originated from  https://bugzilla.mindrot.org/show_bug.cgi?id=1008, but it was changed during rebase to 5.8p1. I think that correct patch should look like this: 	

-       else if (options.gss_trust_dns)
+       else if (options.gss_trust_dns) {
 		gss_host = get_canonical_hostname(1);
+		if ( strcmp( gss_host, "UNKNOWN" )  == 0 )
+			gss_host = authctxt->host;
+       }
	else
		gss_host = authctxt->host;


get_canonical_hostname() returns "UNKNOWN" for connections which are not on a socket.
Comment 6 Marko Myllynen 2012-10-30 05:45:48 EDT
(In reply to comment #5)
> I haven't found any discussion too. It's probably originated from 
> https://bugzilla.mindrot.org/show_bug.cgi?id=1008, but it was changed during
> rebase to 5.8p1. I think that correct patch should look like this: 	
> 
> -       else if (options.gss_trust_dns)
> +       else if (options.gss_trust_dns) {
>  		gss_host = get_canonical_hostname(1);
> +		if ( strcmp( gss_host, "UNKNOWN" )  == 0 )
> +			gss_host = authctxt->host;
> +       }
> 	else
> 		gss_host = authctxt->host;
> 
> 
> get_canonical_hostname() returns "UNKNOWN" for connections which are not on
> a socket.

With this patch GSSAPITrustDNS controls whether the reverse mapping gets done as expected. The rdns directive in krb5.conf is still ignored but that's a separate issue I think.
Comment 7 Petr Lautrbach 2012-10-30 07:27:19 EDT
F18 branch commit 52c8eca4d9521e14bf205abca658893e38c24d9b
Comment 8 Fedora Update System 2012-10-31 12:20:04 EDT
openssh-5.9p1-27.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/openssh-5.9p1-27.fc17
Comment 9 Fedora Update System 2012-10-31 21:27:25 EDT
Package openssh-5.9p1-27.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openssh-5.9p1-27.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-17409/openssh-5.9p1-27.fc17
then log in and leave karma (feedback).
Comment 10 Fedora Update System 2012-12-03 05:21:10 EST
openssh-6.1p1-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/openssh-6.1p1-3.fc18
Comment 11 Marko Myllynen 2012-12-03 08:11:39 EST
(In reply to comment #10)
> openssh-6.1p1-3.fc18 has been submitted as an update for Fedora 18.

The update fixes the issue, Karma added to Bodhi, thanks!
Comment 12 Fedora Update System 2012-12-06 02:22:09 EST
openssh-6.1p1-3.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 13 Fedora Update System 2012-12-20 11:24:27 EST
openssh-5.9p1-27.fc17 has been pushed to the Fedora 17 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.