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
}}}

{i} 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.