Comment Kerberos fonctionne-t-il avec SSH?

22

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

linux ssh authentication kerberos Phil
la source

Réponses:

27

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" 1
  • 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.

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

grawity
la source
Pourriez-vous élaborer sur la relation entre le mot de passe, TGT et la réponse du KDC? Il n'est pas clair comment PAM décide si le mot de passe est correct.
Phil
REMARQUE: cette phrase est incorrecte: "S1 envoie un TGS-REQ et reçoit un TGS-REP contenant le TGT." Incorrect car les TGT font partie de l'AS_REP. Un ticket de service reviendra avec le TGS_REPn
jouell
1
Les versions récentes d'OpenSSH ont un échange de clés. Je pense que 4.2p1 a été la première version à avoir les correctifs. ( sxw.org.uk/computing/patches/openssh.html )
quinnr
Non, ils ne le font pas. Ce sont des correctifs tiers . C'est ce que je voulais dire par "non accepté dans OpenSSH officiel"
grawity
0

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.

yrk
la source
-2

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.

themel
la source
2
Répondre à une question qui demande des détails avec "Je ne vois pas l'avantage de développer les détails" me semble assez grossier.
Massimo