[Freeipa-users] Keberos authentication - Unspecified GSS failure

Simo Sorce simo at redhat.com
Wed Apr 16 22:18:42 UTC 2014


On Wed, 2014-04-16 at 18:13 -0400, Rob Crittenden wrote:
> David Kreuter wrote:
> > Yesterday I installed the FreeIPA client on machine and after the
> > installation the login with password worked fine. After that I tried to
> > login with a valid Kerberos ticket and it failed. First i traced the ssh
> > login:
> >
> > ssh -vvv david at test.example.com
> > ---cut---
> > debug2: key: /home/david/.ssh/id_rsa (0x7f2ad3112d80),
> > debug2: key: /home/david/.ssh/id_dsa ((nil)),
> > debug2: key: /home/david/.ssh/id_ecdsa ((nil)),
> > debug1: Authentications that can continue:
> > publickey,gssapi-keyex,gssapi-with-mic
> > debug3: start over, passed a different list
> > publickey,gssapi-keyex,gssapi-with-mic
> > debug3: preferred
> > gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
> > debug3: authmethod_lookup gssapi-keyex
> > debug3: remaining preferred:
> > gssapi-with-mic,publickey,keyboard-interactive,password
> > debug3: authmethod_is_enabled gssapi-keyex
> > debug1: Next authentication method: gssapi-keyex
> > debug1: No valid Key exchange context
> > debug2: we did not send a packet, disable method
> > debug3: authmethod_lookup gssapi-with-mic
> > debug3: remaining preferred: publickey,keyboard-interactive,password
> > debug3: authmethod_is_enabled gssapi-with-mic
> > debug1: Next authentication method: gssapi-with-mic
> > debug2: we sent a gssapi-with-mic packet, wait for reply
> > debug1: Authentications that can continue:
> > publickey,gssapi-keyex,gssapi-with-mic
> > debug2: we sent a gssapi-with-mic packet, wait for reply
> > debug1: Authentications that can continue:
> > publickey,gssapi-keyex,gssapi-with-mic
> > debug2: we sent a gssapi-with-mic packet, wait for reply
> > debug1: Authentications that can continue:
> > publickey,gssapi-keyex,gssapi-with-mic
> > debug2: we sent a gssapi-with-mic packet, wait for reply
> > debug1: Authentications that can continue:
> > publickey,gssapi-keyex,gssapi-with-mic
> > debug2: we did not send a packet, disable method
> > debug3: authmethod_lookup publickey
> > debug3: remaining preferred: keyboard-interactive,password
> > debug3: authmethod_is_enabled publickey
> > debug1: Next authentication method: publickey
> > debug1: Offering RSA public key: /home/david/.ssh/id_rsa
> > debug3: send_pubkey_test
> > debug2: we sent a publickey packet, wait for reply
> > debug1: Authentications that can continue:
> > publickey,gssapi-keyex,gssapi-with-mic
> > debug1: Trying private key: /home/david/.ssh/id_dsa
> > debug3: no such identity: /home/david/.ssh/id_dsa: No such file or directory
> > debug1: Trying private key: /home/david/.ssh/id_ecdsa
> > debug3: no such identity: /home/david/.ssh/id_ecdsa: No such file or
> > directory
> > debug2: we did not send a packet, disable method
> > debug1: No more authentication methods to try.
> > Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
> > ---cut---
> >
> > Then I enabled the log for SSH on the IPA client machine and faced
> > following error:
> >
> > ---cut---
> > Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 0 failures 0
> > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: initializing for "david"
> > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_RHOST to
> > "10.100.3.2"
> > Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_TTY to "ssh"
> > Apr 16 23:43:18 infra01 sshd[9941]: debug1: userauth-request for user
> > david service ssh-connection method gssapi-with-mic
> > Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 1 failures 0
> > Apr 16 23:43:18 infra01 sshd[9940]: debug1: Unspecified GSS failure.
> >   Minor code may provide more information\nNo key table entry found
> > matching host/infra01@\n
> > ---cut---
> >
> > Unspecified GSS failure.  Minor code may provide more information.No key
> > table entry found matching host/infra01@\n.
> >
> > After that I tried to receive a ticket on the IPA client machine and
> > everything worked fine:
> >
> > kinit <user>
> > klist
> > Ticket cache: FILE:/tmp/krb5cc_0
> > Default principal: david@<realm>.INFO
> >
> > Valid starting     Expires            Service principal
> > 04/16/14 23:24:51  04/17/14 23:24:47  krbtgt/...
> > 04/16/14 23:25:51  04/17/14 23:24:47  host/...
> >
> > kvno -k /etc/krb5.keytab host/...
> > host/...: kvno = 1, keytab entry valid
> >
> > So the Kerberos setup on the machine seems to be fine, but still the
> > login SSH using Keberos is not working. GSSAPI is correctly enabled in
> > the sshd configuration file. Any hint is highly appreciated. Thanks.
> >
> 
> Seems like sshd looked for the wrong key. Run klist -kt /etc/krb5.keytab 
> and see what principal is there. sshd didn't look for a FQDN according 
> to your log.

FYI:
If your hosts for some reason has a non qualified name and you can't fix
the issue due to some other broken software requiring short,
unqualified, hostnames, you can look into setting the following in
krb5.conf:  ignore_acceptor_hostname = true

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Freeipa-users mailing list