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?

Improve this question
2
  • Just to cover the basics, have you checked if the clocks on all machines are synchronized? Commented Feb 19, 2013 at 14:36
  • These are all lxc containers running on the same physical host. Clocks couldn't be more synchronized than this. Commented Feb 21, 2013 at 20:37

2 Answers 2

Reset to default
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.

Improve this answer
3
  • 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? Commented Feb 26, 2013 at 21:04
  • Very well, I updated my answer with further things you should check. It is most likely a short name / FQDN confusion. Commented Feb 27, 2013 at 1: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. Commented Feb 28, 2013 at 7: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?

Improve this answer
1
  • DNS is fine. Only localhost entries in /etc/hosts. Commented Feb 26, 2013 at 20:58

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.