Comment Kerberos fonctionne-t-il avec SSH?

Supposons que j'ai quatre ordinateurs, Laptop, Server1, Server2, Kerberos server:

• Je me connecte en utilisant PuTTY ou SSH de L à S1, en donnant mon nom d'utilisateur / mot de passe
• De S1 I puis SSH à S2. Aucun mot de passe n'est nécessaire car Kerberos m'authentifie

Décrivez tous les échanges de protocole SSH et KRB5 importants: "L envoie le nom d'utilisateur à S1", "K envoie ... à S1" etc.

(Cette question est destinée à être éditée par la communauté; veuillez l'améliorer pour le lecteur non expert .)

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'eux
• L choisit "mot de passe" et envoie le mot de passe simple à S1
• S1 donne le nom d'utilisateur et le mot de passe à la pile PAM.
• Sur S1, PAM (généralement pam_krb5ou pam_sss) demande un TGT (ticket d'octroi de ticket) au Kerberos KDC.
  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 crypter l'horodatage actuel et le joint à l'AS-REQ. Le serveur déchiffre l'horodatage et vérifie qu'il est dans le décalage temporel autorisé; si le déchiffrement échoue, le mot de passe est immédiatement rejeté. Sinon, un TGT est renvoyé dans l'AS-REP.
  2. S1 tente de décrypter 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 la $KRB5CCNAMEvariable d'environnement pour trouver le ccache ou l'utiliser klistpour répertorier son contenu.)
• S1 utilise PAM pour effectuer des vérifications d'autorisation (en fonction de la configuration) et ouvrir la session.
  • Si pam_krb5est appelé en phase d'autorisation, il vérifie s'il ~/.k5loginexiste. Si tel 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 une demande de nom d'utilisateur et 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 , en envoyant un TGS-REQ avec le TGT au KDC, et en recevant un TGS-REP avec le ticket de service de celui-ci.host/s2.example.com@EXAMPLE.COM
• S1 génère un "AP-REQ" (demande d'authentification) et l'envoie à S2.
• S2 tente de décrypter la demande. 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 crypter une transmission de données supplémentaire avec une "clé de session" 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 pour S1.
• Si le transfert des informations d'identification a été activé et que le TGT a le drapeau "transmissible", alors S1 demande une copie du TGT de l'utilisateur (avec le drapeau "transféré" défini) et l'envoie à S2, où il est stocké dans un nouveau ccache. Cela permet des 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 vous connecter 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 MIT (GSSAPI), bien que vous devez activer le transfert (délégation) manuellement.

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

Pour faire court: idéalement, les tickets Kerberos doivent être obtenus sur votre terminal (L), soit avec une kinitcommande, soit dans le cadre de la séquence de connexion locale dans une configuration dite de "connexion unique". Les systèmes distants (S1, S2) seraient alors accessibles sans invites de mot de passe. Un accès chaîné (L → S1 → S2) serait possible en utilisant une technique connue sous le nom de «transfert de ticket». Une telle configuration nécessite notamment que le KDC soit directement accessible depuis le terminal (L).

L'autre réponse de grawity explique cette approche en détail.

La seule étape non évidente ici serait qu'il existe un module PAM sur S1 qui a utilisé vos informations d'identification pour effectuer un kinitet vous obtient un ticket d'octroi de ticket de K (authentification client). Ensuite, lorsque vous SSH vers S2 à l'aide de l'authentification Kerberos, une authentification du service client a lieu. Je ne vois pas l'avantage de passer par tous les échanges fastidieux message par message.

Jetez un -vvvsur votre commande ssh si vous voulez voir chaque message et lire la description Wikipedia de Kerberos.