L'authentification SSH Kerberos échoue avec «Wrong principal in request / Got no client credentials» sur debian squeeze


8

J'ai un hôte Debian Squeeze où je ne peux pas me connecter avec Kerberos sans invite de mot de passe. Un hôte ubuntu 12.04 configuré de manière identique fonctionne correctement et peut se connecter sans obtenir d'invite de mot de passe.

Après un kinit, klist donne:

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

Maintenant, lorsque j'essaie de me connecter via ssh à debian-squeeze, je reçois l'invite de mot de passe. Si je vérifie mes tickets à ce stade sans faire d'authentification, j'obtiens:

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

Donc, évidemment, je reçois un billet accordé. Pourtant, le journal de débogage ssh donne:

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

C'est assez similaire à ce qui est décrit ici , ici et dans ce rapport de bogue .

Mon DNS va bien. Déjà essayé de recréer les principaux / clés. Donc, aucune des solutions n'a aidé qui a été publiée là-bas.

Des indices?


Juste pour couvrir les bases, avez-vous vérifié si les horloges de toutes les machines sont synchronisées?
chutz

Ce sont tous des conteneurs lxc fonctionnant sur le même hôte physique. Les horloges ne pourraient pas être plus synchronisées que cela.
b0ti

Réponses:


7

Dans l'exemple de sortie, je vois que vous avez obtenu une clé pour un debian-squeeze- un nom d'hôte sans aucun point. Cela prouve en quelque sorte que vous avez configuré votre résolution inverse pour pointer vers le nom court. Est-ce vraiment un nom non-FQDN que vous voyez, ou a-t-il été modifié pour la question?

Kerberos devrait fonctionner avec l'un ou l'autre, mais vous pouvez vérifier que l'hôte lui-même pense qu'il est appelé debian-squeeze. Vérifiez que la recherche directe -> inverse à l'intérieur debian-squeezese résout vraiment à debian-squeeze:

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

Je n'ai pas vraiment entendu parler du déploiement de Kerberos avec des noms courts, donc si vous avez le choix, ce peut être une bonne idée de s'en tenir aux FQDN.

Mise à jour:

Le client obtient actuellement une clé pour le nom court, mais le serveur pense qu'il est correctement nommé avec un nom long. Le problème est probablement là. Pour être sûr, essayez ce qui suit:

  1. Vérifiez la recherche de nom avant / arrière à partir du client. C'est à dire

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

    Le nom renvoyé est celui pour lequel le client tentera d'obtenir un ticket. A en juger par votre sortie, c'est probablement le nom court.

  2. Vérifiez les clés présentes sur le serveur.

    $ 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
    ...
    

    Dans la liste, vous devriez voir un principal correspondant au nom d'hôte de la commande précédente. Si ce n'est pas le cas, c'est votre problème. S'il est là ...

  3. Vérifiez que la version de clé sur le serveur Kerberos est la même que celle sur debian-squeeze. Sur le client, obtenez une clé explicitement et vérifiez la version "KVNO" à la fin de la ligne:

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

Dans tous les cas, le nom d'hôte et la version "kvno" dans toutes ces commandes doivent correspondre.


L'hôte est appelé «debian-squeeze» tel que renvoyé par hostname. L'adresse IP est renvoyée au nom de domaine complet, donc la commande que vous avez donnée renvoie «debian-squeeze.realm». En remarque: j'ai deux clés configurées pour cet hôte, une pour le fqdn et une pour le nom court. Cela pourrait-il gâcher?
b0ti

Très bien, j'ai mis à jour ma réponse avec d'autres choses que vous devriez vérifier. Il s'agit très probablement d'une confusion entre nom court et nom de domaine complet.
chutz

Merci beaucoup! Mon problème était en effet causé par la clé supplémentaire avec le nom d'hôte court. Je souhaite juste qu'il serait plus facile de déboguer de tels problèmes afin que les journaux indiquent quel est le principal problématique.
b0ti

0

J'ai vu cette erreur lorsque / etc / hosts sur le serveur inclut une entrée pour son adresse IP qui ne correspond pas à ce qui est dans DNS ou dans le keytab. Avez-vous vérifié (ou supprimé) toutes les entrées non locales de / etc / hosts?


DNS est très bien. Seules les entrées localhost dans / etc / hosts.
b0ti
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.