Frage Wie arbeitet Kerberos mit SSH?


Angenommen, ich habe vier Computer: Laptop, Server1, Server2, Kerberos-Server:

  • Ich logge mich mit PuTTY oder SSH von L bis S1 ein und gebe meinen Benutzernamen / mein Passwort ein
  • Von S1 I dann SSH zu S2. Kein Passwort ist erforderlich, da Kerberos mich authentifiziert

Beschreiben Sie alle wichtigen SSH- und KRB5-Protokolle: "L sendet Benutzername an S1", "K sendet ... an S1" usw.

(Diese Frage soll von der Community bearbeitet werden. Bitte verbessern Sie sie für den Nicht-Experten-Leser.)


20
2017-11-10 19:34


Ursprung




Antworten:


Erste Anmeldung:

  • L sendet Benutzernamen und SSH-Authentifizierungsanfrage an S1
  • S1 gibt verfügbare SSH-Authentifizierungsmechanismen zurück, mit "Passwort" als einer davon
  • L wählt "Passwort" aus und sendet das Plain-Passwort an S1
  • S1 gibt Benutzernamen und Passwort an den PAM-Stack.
  • Auf S1, PAM (normalerweise pam_krb5 oder pam_sss) fordert ein TGT (ticket-granting ticket) vom Kerberos-KDC an.
    1. S1 erhält ein TGT.
      • Old style (ohne preauth): S1 sendet eine AS-REQ und erhält eine AS-REP mit dem TGT.
      • Neuer Stil (mit preauth): S1 verwendet Ihr Passwort, um den aktuellen Zeitstempel zu verschlüsseln und verbindet ihn mit dem AS-REQ. Der Server entschlüsselt den Zeitstempel und überprüft, ob er innerhalb des zulässigen Zeitversatzes liegt. Wenn die Entschlüsselung fehlschlägt, wird das Kennwort sofort zurückgewiesen. Andernfalls wird ein TGT im AS-REP zurückgegeben.
    2. S1 versucht das TGT mit einem Schlüssel zu entschlüsseln, der aus Ihrem Passwort generiert wurde. Wenn die Entschlüsselung erfolgreich ist, wird das Passwort als korrekt akzeptiert.
    3. Das TGT wird in einem neu erstellten Berechtigungsnachweis-Cache gespeichert. (Sie können die $KRB5CCNAME Umgebungsvariable, um den Ccache zu finden, oder zu verwenden klist um seinen Inhalt aufzulisten.)
  • S1 führt mit PAM Berechtigungsprüfungen durch (konfigurationsabhängig) und öffnet die Sitzung.
    • Ob pam_krb5 In der Berechtigungsstufe wird geprüft, ob ~/.k5login existiert. Wenn dies der Fall ist, muss der Client-Kerberos-Prinzipal aufgelistet werden. Ansonsten ist der einzige zulässige Prinzipal Nutzername@DEFAULT-REALM.

Zweiter Login:

  • S1 sendet Benutzernamen und SSH-Authn-Anfrage an S2
  • S2 gibt verfügbare Auth-Mechs zurück, von denen einer "gssapi-with-mic" ist 1
  • S1 fordert ein Ticket für host/s2.beispiel.com@BEISPIEL.COM, indem ein TGS-REQ mit dem TGT an das KDC gesendet wird und ein TGS-REP mit dem Serviceticket von diesem empfangen wird.
  • S1 erzeugt eine "AP-REQ" (Authentifikationsanforderung) und sendet sie an S2.
  • S2 versucht, die Anfrage zu entschlüsseln. Wenn es erfolgreich ist, wird die Authentifizierung durchgeführt. (PAM wird nicht zur Authentifizierung verwendet.)
    • Andere Protokolle wie LDAP können die weitere Datenübertragung mit einem "Sitzungsschlüssel" verschlüsseln, der in der Anfrage enthalten war; SSH hat jedoch bereits eine eigene Verschlüsselungsschicht ausgehandelt.
  • Wenn die Authentifizierung erfolgreich ist, führt S2 mithilfe von PAM Berechtigungsprüfungen durch und öffnet die Sitzung wie S1.
  • Wenn die Weiterleitung von Anmeldeinformationen aktiviert wurde und das TGT das Flag "Weiterleitbar" hat, fordert S1 eine Kopie des TGT des Benutzers an (mit dem Flag "Weitergeleitet") und sendet es an S2, wo es in einem neuen Cache gespeichert wird. Dies ermöglicht rekursive Kerberos-authentifizierte Logins.

Beachten Sie, dass Sie TGTs auch lokal abrufen können. Unter Linux können Sie dies mit. Tun kinit, dann verbinden mit ssh -K. Wenn Sie in Windows bei einer Windows AD-Domäne angemeldet sind, übernimmt Windows das für Sie. Andernfalls, MIT Kerberos kann verwendet werden. PuTTY 0.61 unterstützt sowohl Windows (SSPI) als auch MIT (GSSAPI), obwohl Sie die Weiterleitung (Delegierung) manuell aktivieren müssen.


1  gssapi-keyex ist auch möglich, wurde aber nicht in offiziellen OpenSSH akzeptiert.


25
2017-11-10 20:43



Könnten Sie die Beziehung zwischen dem Passwort, TGT und der Antwort des KDC näher erläutern? Es ist nicht klar Wie PAM entscheidet, ob das Passwort korrekt ist. - Phil
Hinweis: dieser Satz ist falsch: "S1 sendet ein TGS-REQ und empfängt ein TGS-REP, das das TGT enthält". Falsch, weil TGTs Teil von AS_REP sind. Ein Service Ticket wird mit dem TGS_REPn zurückkommen - jouell
Aktuelle Versionen von OpenSSH haben Schlüsselaustausch. Ich denke, 4.2p1 war die erste Version, die die Patches hatte. (sxw.org.uk/computing/patches/openssh.html) - quinnr
Nein, tun sie nicht. Diese sind dritte Seite Patches. Das meinte ich mit "nicht akzeptiert in offiziellen OpenSSH" - grawity


Um es kurz zu machen: Im Idealfall sollten Kerberos-Tickets auf Ihrem Terminal (L) entweder mit erhalten werden kinit Befehl oder als Teil der lokalen Login-Sequenz in einem sogenannten "Single Sign-On" Setup. Die entfernten Systeme (S1, S2) wären dann ohne Passwortaufforderungen zugänglich. Ein verketteter Zugriff (L → S1 → S2) wäre möglich, indem eine Technik angewendet wird, die als "Ticketweiterleitung" bekannt ist. Ein solcher Aufbau erfordert insbesondere, dass das KDC direkt von dem Endgerät (L) aus zugänglich ist.

Die andere Antwort von Grausamkeit erklärt diesen Ansatz im Detail.


0
2018-03-28 11:10





Der einzige nicht offensichtliche Schritt wäre hier, dass es ein PAM-Modul auf S1 gibt, das Ihre Anmeldeinformationen verwendet, um eine kinit und bekommt von K ein Ticket-Bewilligungs-Ticket (Client-Authentifizierung). Wenn Sie SSH-S2 mit Kerberos-Authentifizierung verwenden, wird eine Client-Dienstauthentifizierung ausgeführt. Ich sehe den Vorteil nicht, alle langwierigen Nachrichten zwischen Nachrichten auszutauschen.

Werfen Sie einen -vvv auf Ihrem ssh - Befehl, wenn Sie jede Nachricht sehen und lesen möchten Wikipedia Beschreibung von Kerberos.


-2
2017-11-10 20:33



Beantworten einer Frage, die fragt Einzelheiten mit "Ich sehe nicht den Vorteil der Ausarbeitung der Details" scheint mir ziemlich unhöflich. - Massimo