Wie funktioniert Kerberos mit SSH?

Erste Anmeldung:

• L sendet den Benutzernamen und die SSH-Authentifizierungsanfrage an S1
• S1 gibt verfügbare SSH-Authentifizierungsmechanismen zurück, darunter "Passwort"
• L wählt "Passwort" und sendet das einfache Passwort an S1
• S1 übergibt Benutzername 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.
     • Alter Stil (ohne Preauth):S1 sendet ein AS-REQ und empfängt ein AS-REP, das das TGT enthält.
     • Neuer Stil (mit Preauth):S1 verwendet Ihr Passwort, um den aktuellen Zeitstempel zu verschlüsseln, und hängt es an die 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 zurückgewiesen. 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 Berechtigungsnachweise gespeichert. (Sie können den $KRB5CCNAME überprüfen Umgebungsvariable, um den Cache zu finden, oder verwenden Sie klist um seinen Inhalt aufzulisten.)
• S1 verwendet PAM, um Berechtigungsprüfungen durchzuführen (konfigurationsabhängig) und die Sitzung zu öffnen.
  • Falls pam_krb5 in der Autorisierungsphase aufgerufen wird, prüft es, ob ~/.k5login existiert. Wenn dies der Fall ist, muss der Client-Kerberos-Prinzipal aufgelistet werden. Andernfalls ist username@DEFAULT-REALM der einzig zulässige Prinzipal .

Zweites Login:

• S1 sendet den Benutzernamen und die SSH-Authentifizierungsanfrage an S2
• S2 gibt verfügbare Auth-Mechs zurück, einer davon ist "gssapi-with-mic"
• S1 fordert ein Ticket für host/s2.example.com@EXAMPLE.COM an , indem Sie eine TGS-REQ mit dem TGT an das KDC senden und von dort eine TGS-REP mit dem Service-Ticket erhalten.
• S1 generiert eine "AP-REQ" (Authentifizierungsanfrage) und sendet sie an S2.
• S2 versucht, die Anfrage zu entschlüsseln. Wenn dies gelingt, ist die Authentifizierung abgeschlossen. (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, verwendet S2 PAM, um Autorisierungsprüfungen durchzuführen und die Sitzung zu öffnen, genau wie S1.
• Wenn die Berechtigungsweiterleitung aktiviert war und das TGT das Flag „forwardable“ hat, fordert S1 eine Kopie des TGT des Benutzers an (mit gesetztem „forwarded“-Flag) und sendet es an S2, wo es in einem neuen Cache gespeichert wird . Dies ermöglicht rekursive Kerberos-authentifizierte Anmeldungen.

Beachten Sie, dass Sie TGTs auch lokal erhalten können. Unter Linux können Sie dies mit kinit tun , verbinden Sie sich dann mit ssh -K . Wenn Sie bei Windows bei einer Windows AD-Domäne angemeldet sind, erledigt Windows dies für Sie; andernfalls kann MIT Kerberos verwendet werden. PuTTY 0.61 unterstützt sowohl die Verwendung von Windows (SSPI) als auch MIT (GSSAPI), obwohl Sie die Weiterleitung (Delegation) manuell aktivieren müssen.

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