Wie funktioniert Kerberos mit SSH?

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

• Ich melde mich mit PuTTY oder SSH von L bis S1 mit meinem Benutzernamen / Passwort an
• Von S1 I dann SSH nach S2. Es wird kein Passwort benötigt, da Kerberos mich authentifiziert

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

(Diese Frage ist für die Bearbeitung durch die Community gedacht. Bitte verbessern Sie sie für nicht sachkundige Leser .)

Erstes Login:

• L sendet einen Benutzernamen und eine SSH-Authentifizierungsanforderung an S1
• S1 gibt verfügbare SSH-Authentifizierungsmechanismen mit "Passwort" als einem davon zurück
• L wählt "Passwort" und sendet das einfache Passwort an S1
• S1 gibt dem PAM-Stack Benutzernamen und Passwort.
• Auf S1 fordert PAM (normalerweise pam_krb5oder pam_sss) ein TGT (Ticket Granting Ticket) vom Kerberos KDC an.
  1. S1 erhält eine TGT.
     • Alter Stil (ohne Preauth): S1 sendet einen AS-REQ und empfängt einen AS-REP mit dem TGT.
     • Neuer Stil (mit Preauth): S1 verschlüsselt mit Ihrem Passwort den aktuellen Zeitstempel und hängt ihn an den AS-REQ an. 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 Passwort sofort abgelehnt. Andernfalls wird im AS-REP ein TGT zurückgegeben.
  2. S1 versucht, das TGT mit einem aus Ihrem Passwort generierten Schlüssel zu entschlüsseln. Wenn die Entschlüsselung erfolgreich ist, wird das Passwort als korrekt akzeptiert.
  3. Das TGT wird in einem neu erstellten Cache für Anmeldeinformationen gespeichert. (Sie können die $KRB5CCNAMEUmgebungsvariable untersuchen, um den Ccache zu finden, oder klistdessen Inhalt auflisten .)
• S1 verwendet PAM, um Berechtigungsprüfungen durchzuführen (konfigurationsabhängig) und die Sitzung zu öffnen.
  • Wenn pam_krb5in der Berechtigungsphase aufgerufen wird, wird geprüft, ob ~/.k5loginvorhanden. In diesem Fall muss der Client-Kerberos-Principal aufgelistet werden. Andernfalls ist der einzige zulässige Principal .username@DEFAULT-REALM

Zweiter Login:

• S1 sendet Benutzernamen und SSH-Authn-Anfrage an S2
• S2 gibt verfügbare Authentifizierungsmechanismen zurück, von denen eine "gssapi-with-mic" ^{1 ist}
• S1 fordert ein Ticket für an , indem ein TGS-REQ mit dem TGT an das KDC gesendet und ein TGS-REP mit dem Serviceticket von diesem empfangen wird.host/s2.example.com@EXAMPLE.COM
• S1 generiert eine "AP-REQ" (Authentifizierungsanfrage) und sendet diese an S2.
• S2 versucht die Anfrage zu entschlüsseln. Wenn dies 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 Anforderung enthalten war. SSH hat jedoch bereits eine eigene Verschlüsselungsschicht ausgehandelt.
• Wenn die Authentifizierung erfolgreich ist, verwendet S2 PAM, um Autorisierungsprüfungen durchzuführen und die Sitzung zu öffnen, genau wie S1.
• Wenn die Weiterleitung von Anmeldeinformationen aktiviert war und der TGT das Flag "Weiterleitbar" hat, fordert S1 eine Kopie des TGT des Benutzers an (wobei das Flag "Weitergeleitet" gesetzt ist) und sendet sie an S2, wo sie in einem neuen Cache gespeichert wird. Dies ermöglicht rekursive Kerberos-authentifizierte Anmeldungen.

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

¹ gssapi-keyex ist ebenfalls möglich, wurde aber nicht in das offizielle OpenSSH aufgenommen.

Um es kurz zu machen: Im Idealfall sollten Kerberos-Tickets auf Ihrem Terminal (L) entweder mit einem kinitBefehl oder als Teil der lokalen Anmeldesequenz in einem sogenannten "Single Sign-On" -Setup abgerufen werden. Die entfernten Systeme (S1, S2) wären dann ohne Passwortabfragen erreichbar. Ein verketteter Zugriff (L → S1 → S2) wäre unter Verwendung einer Technik möglich, die als "Ticketweiterleitung" bekannt ist. Für einen solchen Aufbau muss insbesondere der KDC direkt vom Terminal (L) aus erreichbar sein.

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

Der einzige nicht offensichtliche Schritt hier wäre, dass es ein PAM-Modul auf S1 gibt, das Ihre Anmeldeinformationen verwendet, um kinitein Ticket auszuführen und Ihnen ein Ticket von K (Clientauthentifizierung) zu erteilen. Wenn Sie dann mithilfe der Kerberos-Authentifizierung eine SSH-Verbindung zu S2 herstellen, findet eine Client-Dienst-Authentifizierung statt. Ich sehe keinen Vorteil darin, den langwierigen Austausch Nachricht für Nachricht durchzugehen.

-vvvWenn Sie jede Nachricht sehen und die Wikipedia-Beschreibung von Kerberos lesen möchten, geben Sie einen in Ihrem ssh-Befehl ein .