Créer les entrées pour SSH (exemple depuis le serveur du BAP2) :
kadmin -p root/admin kadmin: addprinc -randkey host/server.bap2.vn.auf kadmin: ktadd -k /etc/krb5.keytab host/server.bap2.vn.auf kadmin: exit
Puis configurer ceci dans /etc/ssh/sshd_config côté serveur :
# GSSAPI options GSSAPIAuthentication yes GSSAPICleanupCredentials yes
Et relancer le service SSH :
/etc/init.d/ssh restart
Et enfin configurer ceci dans /etc/ssh/ssh_config (ou ~/.ssh/config) côté client :
GSSAPIAuthentication yes
Il faut faire attention à ce que le hostname corresponde bien entre :
celui ajouté dans Kerberos via kadmin ;
celui donné par la commande hostname -f sur le serveur (sinon vérifier /etc/hostname et /etc/hosts) ;
- celui utilisé dans la commande de connexion SSH sur le client.
En cas d'incohérence entre les hostname, on aura un message d'erreur de ce type dans les logs de Kerberos :
krb5kdc[...]: TGS_REQ ... UNKNOWN_SERVER: ... utilisateur@REALM for host/mauvais-nom-d-hote@REALM, Server not found in Kerberos database
En cas de bon fonctionnement, mais lenteur à la connexion, il s'agit presque toujours d'un problème de résolution DNS (souvent inverse) qui se passe mal. Il faut donc vérifier si la résolution DNS du nom du serveur — _et_ de son adresse IP — fonctionne côté serveur mais également côté client et donne bien le même résultat partout.
On notera l'option -K du client SSH qui fait suivre la gestion Kerberos locale sur la connexion, ce qui permet de continuer à utiliser ses accès Kerberos depuis l'hôte sur lequel on s'est connecté. Il y a évidement des risques similaires à ceux lors de l'utilisation de -A et il ne faut donc utiliser cette option que lorsqu'on est sûr de la sécurité du système sur lequel on se connecte.