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.
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?
The reporter of this bug is an idiot. See /etc/hosts.