8

I have a debian squeeze host where I can't log in with kerberos without a password prompt. An identically configured ubuntu 12.04 host works fine and can log in without getting a password prompt.

After a kinit, klist gives:

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: boti@REALM

Valid starting    Expires           Service principal
14/02/2013 16:37  15/02/2013 16:37  krbtgt/REALM@REALM

Now when I try to log in over ssh into debian-squeeze I'm presented with the password prompt. If I check my tickets at this point without doing an auth, I get:

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: boti@REALM

Valid starting    Expires           Service principal
14/02/2013 16:37  15/02/2013 16:37  krbtgt/REALM@REALM
14/02/2013 16:38  15/02/2013 16:37  host/debian-squeeze@
14/02/2013 16:38  15/02/2013 16:37  host/debian-squeeze@REALM

So obviously I get a ticket granted. Yet the ssh debug log gives:

Postponed gssapi-with-mic for boti from 192.168.255.98 port 59557 ssh2
debug3: mm_request_send entering: type 40
debug3: mm_request_receive_expect entering: type 41
debug3: mm_request_receive entering
debug3: monitor_read: checking request 40
debug1: Unspecified GSS failure.  Minor code may provide more information
Wrong principal in request

This is pretty similar what is described here, here and in this bugreport.

My DNS is fine. Already tried recreating the principals/keys. So none of the solutions helped which were posted there.

Any hints?

Community
  • 1
b0ti
  • 986
  • 1
  • 6
  • 13
  • Just to cover the basics, have you checked if the clocks on all machines are synchronized? – chutz Feb 19 '13 at 14:36
  • These are all lxc containers running on the same physical host. Clocks couldn't be more synchronized than this. – b0ti Feb 21 '13 at 20:37

2 Answers2

7

In the sample output I see that you got a key for a debian-squeeze -- a hostname without any dots in it. This does kind of prove that you set up your reverse resolution to point to the short name. Is that really a non-FQDN name that you see, or was it edited for the question?

Kerberos should work with either, but you may to double check that the host itself thinks it is called debian-squeeze. Check that the forward -> reverse lookup inside debian-squeeze really resolves to debian-squeeze:

$ getent hosts $(hostname) | awk '{print $1; exit}' | xargs getent hosts | awk '{print $2}'

I haven't really heard of Kerberos being deployed with short names, so if you have a choice, it may be a good idea to stick with FQDNs.

Update:

The client is currently getting a key for the short name, but the server thinks it is properly named with a long name. Most likely the issue is there. Just to be sure, try the following:

  1. Check the forward/reverse name lookup from the client. I.e.

    $ getent hosts debian-squeeze | awk '{print $1; exit}' | xargs getent hosts | awk '{print $2}'

    The returned name is the one that the client will try to get a ticket for. Judging by your output, this is probably the short name.

  2. Check what keys are present on the server.

    $ sudo klist -k /etc/krb5.keytab
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 host/debian-squeeze.realm@REALM
   1 host/debian-squeeze.realm@REALM
   1 host/debian-squeeze.realm@REALM
   1 host/debian-squeeze.realm@REALM
...

    In the list you should see a principal matching the hostname from the previous command. If it's not there, then that's your problem. If it is there...

  3. Verify the key version on the kerberos server is the same as the one on debian-squeeze. On the client, get a key explicitly and verify the "KVNO" version at the end of the line:

    $ kvno host/debian-squeeze.realm
host/debian-squeeze.realm@REALM: kvno = 1

At any rate, the hostname and "kvno" version in all these commands should match.

chutz
  • 7,569
  • 1
  • 28
  • 57
  • The host is called 'debian-squeeze' as returned by `hostname`. The IP maps back to FQDN, so the command you gave returns 'debian-squeeze.realm'. As a side-note: I have two keys set up for this host, one for the fqdn and one for the short name. Could this be messing up? – b0ti Feb 26 '13 at 21:04
  • Very well, I updated my answer with further things you should check. It is most likely a short name / FQDN confusion. – chutz Feb 27 '13 at 01:57
  • Thanks a lot! My problem was indeed caused by the extra key with the short hostname. I just wish it would be easier to debug such issues so that the logs indicate what the problematic principal is. – b0ti Feb 28 '13 at 07:48
0

I have seen this error when /etc/hosts on the server includes an entry for its IP address that does not match what is in DNS or the keytab. Have you double checked (or removed) all the non-localhost entries from /etc/hosts?

slushpupie
  • 216
  • 1
  • 2