Bug 752991 - GSSAPI authentication broken when logging via ssh to localhost
GSSAPI authentication broken when logging via ssh to localhost
Product: Fedora
Classification: Fedora
Component: krb5 (Show other bugs)
i686 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-11-10 19:10 EST by Bojan Smojver
Modified: 2011-11-13 01:42 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-11-13 01:42:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bojan Smojver 2011-11-10 19:10:40 EST
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):

How reproducible:

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 11:28:27 EST
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 01:42:51 EST
The reporter of this bug is an idiot. See /etc/hosts.

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