Comment Kerberos fonctionne-t-il avec SSH ?

Première connexion :

• L envoie le nom d'utilisateur et la demande d'authentification SSH à S1
• S1 renvoie les mécanismes d'authentification SSH disponibles, avec "mot de passe" comme l'un d'entre eux
• L sélectionne "mot de passe" et envoie le mot de passe en clair à S1
• S1 donne le nom d'utilisateur et le mot de passe à la pile PAM.
• Sur S1, PAM (généralement pam_krb5 ou pam_sss ) demande un TGT (ticket-granting ticket) au KDC Kerberos.
  1. S1 obtient un TGT.
     • Ancien style (sans pré-autorisation) :S1 envoie un AS-REQ et reçoit un AS-REP contenant le TGT.
     • Nouveau style (avec pré-autorisation) :S1 utilise votre mot de passe pour chiffrer l'horodatage actuel et le joint à l'AS-REQ. Le serveur déchiffre l'horodatage et vérifie qu'il respecte le décalage temporel autorisé ; si le déchiffrement échoue, le mot de passe est immédiatement rejeté. Sinon, un TGT est retourné dans l'AS-REP.
  2. S1 tente de déchiffrer le TGT à l'aide d'une clé générée à partir de votre mot de passe. Si le déchiffrement réussit, le mot de passe est accepté comme correct.
  3. Le TGT est stocké dans un cache d'informations d'identification nouvellement créé. (Vous pouvez inspecter le $KRB5CCNAME variable d'environnement pour trouver le ccache, ou utilisez klist pour lister son contenu.)
• S1 utilise PAM pour effectuer des vérifications d'autorisation (selon la configuration) et ouvrir la session.
  • Si pam_krb5 est appelé en phase d'autorisation, il vérifie si ~/.k5login existe. Si c'est le cas, il doit répertorier le principal Kerberos du client. Sinon, le seul principal autorisé est username@DEFAULT-REALM .

Deuxième connexion :

• S1 envoie le nom d'utilisateur et la demande d'authentification SSH à S2
• S2 renvoie les mécanismes d'authentification disponibles, l'un d'eux étant "gssapi-with-mic"
• S1 demande un ticket pour host/s2.example.com@EXAMPLE.COM , en envoyant un TGS-REQ avec le TGT au KDC, et en recevant un TGS-REP avec le ticket de service de celui-ci.
• S1 génère un "AP-REQ" (demande d'authentification) et l'envoie à S2.
• S2 tente de déchiffrer la requête. S'il réussit, l'authentification est effectuée. (PAM n'est pas utilisé pour l'authentification.)
  • D'autres protocoles tels que LDAP peuvent choisir de chiffrer la transmission de données ultérieure avec une "clé de session" qui a été incluse avec la demande ; cependant, SSH a déjà négocié sa propre couche de chiffrement.
• Si l'authentification réussit, S2 utilise PAM pour effectuer des vérifications d'autorisation et ouvrir la session, comme S1.
• Si le transfert d'informations d'identification a été activé et que le TGT a l'indicateur "transmissible", alors S1 demande une copie du TGT de l'utilisateur (avec l'indicateur "transféré" défini) et l'envoie à S2, où il est stocké dans un nouveau ccache . Cela autorise les connexions récursives authentifiées par Kerberos.

Notez que vous pouvez également obtenir des TGT localement. Sous Linux, vous pouvez le faire en utilisant kinit , puis connectez-vous en utilisant ssh -K . Pour Windows, si vous êtes connecté à un domaine Windows AD, Windows le fait pour vous; sinon, MIT Kerberos peut être utilisé. PuTTY 0.61 prend en charge l'utilisation de Windows (SSPI) et de MIT (GSSAPI), bien que vous deviez activer le transfert (délégation) manuellement.

gssapi-keyex est également possible mais n'a pas été accepté dans OpenSSH officiel.