Bug 752991

Summary:	GSSAPI authentication broken when logging via ssh to localhost
Product:	[Fedora] Fedora	Reporter:	Bojan Smojver <bojan>
Component:	krb5	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	16	CC:	nalin
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-11-13 06:42:51 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Bojan Smojver 2011-11-11 00:10:40 UTC

Description of problem:

Note: this may actually be an OpenSSH of sssd bug - not exactly sure.

A system configured with Kerberos authentication against AD (using sssd) is not succeeding when ssh to localhost is attempted, like this:

ssh -vvv -K localhost
------------------
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Unspecified GSS failure. Minor code may provide more information
Generic error (see e-text)

------------------

klist shows a valid ticket which can be used to log into other systems (e.g. RHEL4).

Other systems can login via ssh into this system using Kerberos without trouble. For instance, an RHEL4 system can login to this host using Kerberos.

Note that /etc/krb5.keytab was (obviously) generated on Windows AD machines (I believe Windows 2003 server, but not 100% sure).

On another system, where /etc/krb5.keytab was generated using MIT krb5 tools and authentication is against MIT krb5 server, doing the same thing works fine.

Version-Release number of selected component (if applicable):
krb5-libs-1.9.1-18.fc16.i686

How reproducible:
Always.

Steps to Reproduce:
1. Obtain /etc/krb5.keytab from AD.
2. Configure Kerberos auth with sssd.
3. ssh -vvv -K localhost

Actual results:
Fails to use Kerberos credentials to log in.

Expected results:
Should work.

Additional info:
There was an old krb5 bug that would cause trouble with AD generated keytabs (something to do with encryption types). Not sure whether this somehow resurfaced.

Comment 1 Nalin Dahyabhai 2011-11-11 16:28:27 UTC

By itself, the 'generic error' message isn't a lot to go on.  Can you retry with KRB5_TRACE set to "/dev/stderr" in the environment and capture the output?

After the failed attempt, does "klist" show that credentials for use against the host's "host" service were obtained from the KDC?

Is 'localhost' an alias for the system's proper name, from which the service's principal name must be computed?  If not, you'll need to give the ssh client the right name.  This can be affected by the contents of /etc/hosts, so I suggest comparing the contents on the file on the old system where 'ssh localhost' works to the contents of the same file on the new system.

What types of keys are available in the server's keytab?  Can you paste the output of "klist -k -t /etc/krb5.keytab" to make sure that it doesn't contain only keys for ciphers which are not enabled unless the "allow_weak_crypto" setting is enabled?

Comment 2 Bojan Smojver 2011-11-13 06:42:51 UTC

The reporter of this bug is an idiot. See /etc/hosts.