Kerberos Tickets haben eine begrenzte Laufzeit und müssen vor Ablauf durch eine erneute Passworteingabe erneuert werden. Der RRZE-Standard sieht eine Ticketlaufzeit von 10 Stunden vor, was für einen normalen Arbeitstag ausreichend ist.
Bei länger laufenden Prozessen, z.B. Simulationen oder sonstige aufwendige Berechnungen kann das Ablaufen des Kerberos Tickets jedoch zu Problemen führen.
Im Folgenden werden die Probleme beschrieben, die bei langlaufenden Prozessen im Zusammenhang mit Kerberos auftreten können und Lösungsmöglichkeiten aufgezeigt.
Problembeschreibung
In der Standardkonfiguration des LINUXKDC ist definiert, das ein Ticket maximal 10 Stunden gültig ist und bis auf maximal 7 Tage verlängert werden kann. (Dies entspricht übrigens auch den Windows-Standardwerten: https://technet.microsoft.com/en-us/library/dd277401.aspx)
Das heißt alle 10 Stunden muss ein Benutzer sein Passwort eingeben, um sein Ticket zu erneuern. Das kann z.B. implizit beim Entsperren des Bildschirms passieren oder explizit durch den Aufruf von kinit (siehe unten) oder erneutes Einloggen. Sperrt man ab und zu seinen Bildschirm (z.B. in der Mittagspause), so wird hier beim Entsperren ein neues Ticket vergeben und es entstehen keine Probleme.
Die Wahl der maximalen Ticketlaufzeit ist ein Kompromiss zwischen Komfort und Sicherheit, da einmal ausgestellte Tickets im Falle des Missbrauchs nicht widerrufen werden können und so für die gesamte Restlaufzeit des Tickets benutzbar bleiben.
Durch Zusatztools wie krenew (siehe unten) kann eine automatisierte Verlängerung des Tickets auf die maximale Laufzeit von 7 Tagen erreicht werden.
Für Prozesse, die über einen längeren Zeitraum Berechnungen anstellen und auf ein gültiges Ticket (z.B. zum Zugriff auf das Home-Verzeichnis) angewiesen sind, kann ein ablaufendes Ticket allerdings zum Problem werden. Eigentlich möchte man sicherstellen, dass das Ticket bis zur Beendigung des Prozesses nicht abläuft.
Lösungsmöglichkeiten
Verschiedene Strategien für langlaufende Prozesse mit Kerberos.
Verlängerte Ticketlaufzeit anfordern (max. 24 Stunden Laufzeit)
Mit kinit kann explizit ein neues Ticket beim LINUXKDC angefordert werden.
Unter Verwendung bestimmter Optionen kann ein länger laufendes bzw. ein spezielles, verlängerbares Ticket erworben werden, um damit langlaufende Prozesse auszuführen. Im Folgenden werden einige Anwendungsszenarien dokumentiert.
Ticket erneuern
Dies ist der Standard-Weg, um ein neues Ticket mit der Standardlaufzeit von 10 Stunden anzufordern oder ein bestehendes zu erneuern.
bash$ kinit Password for [Kennung]@LINUX.FAU.DE: bash$ klist Ticket cache: FILE:/tmp/krb5cc_[UID]_kZe3jz Default principal: [Kennung]@LINUX.FAU.DE Valid starting Expires Service principal 05.04.2017 15:33:55 06.04.2017 01:33:55 krbtgt/LINUX.FAU.DE@LINUX.FAU.DE
Ticket mit erweiterter/definierter Laufzeit anfordern
Die Standardlaufzeit von 10 Stunden ist ein eine clientseitige Beschränkung, die mit einem Parameter auf das serverseitige Limit von 24 Stunden angehoben werden kann.
# Ticket mit einer Laufzeit (lifetime) von 24 Stunden anfordern (=maximal mögliche Laufzeit ohne Verlängerung) bash$ kinit -l 24h Password for [Kennung]@LINUX.FAU.DE: bash$ klist Ticket cache: FILE:/tmp/krb5cc_[UID]_kZe3jz Default principal: [Kennung]@LINUX.FAU.DE Valid starting Expires Service principal 05.04.2017 15:38:13 06.04.2017 15:38:13 krbtgt/LINUX.FAU.DE@LINUX.FAU.DE
Verlängerbares Ticket anfordern
Sollte das immer noch nicht ausreichen, kann ein spezielles, verlängerbares Ticket angefordert werden. Dieses kann für maximal 7 Tage ohne Passworteingabe, aber durch Verwendung von krenew, gültig gehalten werden.
# Ticket mit Verlängerungsmöglichkeit (renewable) auf 7 Tage anfordern (=maximal mögliche Verlängerung) bash$ kinit -r 7d Password for [Kennung]@LINUX.FAU.DE: bash$ klist Ticket cache: FILE:/tmp/krb5cc_[UID]_kZe3jz Default principal: [Kennung]@LINUX.FAU.DE 05.04.2017 15:40:37 06.04.2017 01:40:37 krbtgt/LINUX.FAU.DE@LINUX.FAU.DE renew until 12.04.2017 15:40:37
Beachten Sie die letzte Zeile im Beispiel. Diese zeigt an, dass ein verlängerbares Ticket erworben wurde.
Der Einsatz von krenew wird im folgenden Absatz beschrieben.
Automatisierte Verlängerung durchführen (max. 7 Tage Laufzeit)
Eine Möglichkeit zur automatisierten Verlängerung von Tickets ist die Verwendung von krenew.
So kann automatisiert z.B. jede Stunde geprüft werden, ob das aktuelle Ticket bald abläuft und ggf. eine Verlängerung des Tickets beim LINUXKDC angefordert werden.
Voraussetzung hierfür ist die Verwendung eines erneuerbaren (renewable) Tickets. Wie Sie ein solches Ticket anfordern können finden Sie oben in der Dokumentation zum Befehl kinit (siehe oben).
Installation und Anwendung können wie folgt durchgeführt werden.
bash$ sudo apt-get install kstart ... bash$ klist Ticket cache: FILE:/tmp/krb5cc_[UID]_kZe3jz Default principal: [Kennung]@LINUX.FAU.DE Valid starting Expires Service principal 05.04.2017 12:49:29 05.04.2017 22:49:29 krbtgt/LINUX.FAU.DE@LINUX.FAU.DE renew until 12.04.2017 12:49:29 bash$ krenew -v -- sh -c './compute_job.sh >> compute_job.log' krenew: renewing credentials for [Kennung]@LINUX.FAU.DE
Die Zeile
renew until 12.04.2017 12:49:29
zeigt an bis wann der Job abgeschlossen sein muss, bzw. wie lange das Ticket maximal verlängert werden kann.
Wichtig!
If a command is given, krenew makes a copy of the ticket cache and creates a private ticket cache just for that command, thus isolating it from later destruction of the original ticket cache. This allows krenew to maintain authentication for a command even if, for example, the user running the command logs out and OpenSSH destroys their original ticket cache.
(Auszug aus der Manpage zu krenew)
Das bedeutet, dass das Kommando auch z.B. nach Beendigung einer SSH-Session noch über ein gültiges Ticket verfügt.
Allerdings wird dadurch auch verhindert, dass durch ein erneutes Einloggen beziehungsweise einen Aufruf von kinit das „Kommando-Ticket“ verlängert wird.
Nur lokale Ressourcen verwenden (unbegrenzte Laufzeit)
Durch Verwendung lokaler Ressourcen kann die Abhängigkeit von einem gültigen Kerberos Ticket vermieden werden.
In der Praxis bedeutet das normalerweise, dass alle nötigen Daten auf einer lokalen Festplatte vorgehalten werden müssen oder zumindest nicht im Home-Laufwerk oder einem anderen Netzlaufwerk, das Keberos verwendet, abgelegt sein dürfen.
Falls dies praktikabel ist, stellt es die stabilste Variante dar und ermöglicht eine unbegrenzte Laufzeit des Prozesses.