Wie bereits angekündigt werde ich in den nächsten Wochen einige Aspekte asymmetrischer Kryptographie beschreiben. Der vorliegende Artikel erläutert nochmals SSH PKI und versucht erneut, zu erklären, warum man in Produktivsystemen unbedingt von der Authentifizierung per Schlüssel zu der per Zertifikat übergehen sollte.

Eine weitere Form von Digitalen Identitäten als die bisher vorrangig diskutierten sind die im Zusammenhang mit SSH Remote Verbindungen zwischen Rechnern. Solche Verbindungen beruhen auf dem SSH Protokoll und können für verschiedene Zwecke eingesetzt werden - unter anderem für das Errichten von Tunneln, für die direkte interaktive Arbeit mit Anwendungen auf entfernten Rechnern oder zur Übertragung von Dateien. Alle diese Anwendungsfälle haben gemeinsam, dass die Übertragung der Daten durch den Einsatz asymmetrischer Kryptographie vertraulich erfolgt und die Integrität der Daten sichergestellt ist.

Dies geschieht auch hier unter dem Einsatz digitaler Identitäten, die auch in diesem Fall aus Zertifikaten, öffentlichen und privaten Schlüsseln bestehen. Allerdings sind die Anforderungen zur Authentifizierung andere als im klassischen TLS: Dort ist - wenn man alle Anwendungsfälle betrachtet die Authentifizierung des Client immer noch eher die Ausnahme, während beim Protokoll SecureShell (SSH) eine Authentifizierung seitens des Client die Regel ist. Dieses Protokoll bietet als grundlegenden Mechanismus dafür Passwort-basierte Authentifizierung an. Weitere Mechanismen sind verfügbar und viele Installationen benutzen Authentifizierung mittels eines Keypairs: Der Public Key wird auf dem Server hinterlegt. Bei Initiierung einer Verbindung wird mittels beider Schlüssel ermittelt, ob der Inhaber des privaten Schlüssels (der Client) einen vorweist, der zu einem der auf dem Server hinterlegten Public Keys passt. Ist das der Fall, gilt der Client als authentifiziert und die Verbindung wird etabliert.

Das Problem mit diesem Ansatz ist, dass Schlüssel keine Lifetime haben. Schlüssel werden nicht ungültig. Wenn man also ein echtes Multi-User-Szenario mit mehreren Rechnern annimmt und den Use Case beleuchtet, dass einem der berechtigten Nutzer aus einem beliebigen Grund diese Berechtingung entzogen werden soll, müssen von allen betroffenen Rechnern die Schlüssel dieses Benutzers entfernt werden. Dies erzeugt einen hohen Aufwand und ist eventuell - auch abhängig von der Frequenz des Auftretens dieses Falles - gar nicht durchführbar. Über die Fehleranfälligkeit dieses Verfahrens muss ich, glaube ich, gar nichts sagen.

Es besteht aber die Möglichkeit, eine PKI aufzusetzen - dieses Mal aber für SSH-Identitäten. In diesem Fall werden statt der Public Keys aller Berechtigten nur die Identität der CA (oder CAs) auf den Servern hinterlegt. Um sich authentifizieren zu können muss der Client nun seine digitale Identität von der CA bestätigen lassen. Dies geschieht, indem die CA ein entsprechendes Zertifikat ausstellt, das für die Authentifizierung benutzt wird. Der Server checkt nun, ob ein während der Authentifizierung vorgewiesenes Zertifikat von einer der CAs ausgestellt wurde, deren Zertifikate auf dem Server hinterlegt sind. Ist das der Fall, gilt der Client als authentifiziert und die Verbindung kommt zustande. Der Unterschied zwischen Zertifikaten und Keys ist, dass Zertifikate eine begrenzte Lebenszeit haben, die beliebig kurz sein kann. Man kann also die CA so konfigurieren, dass Zertifikate beispielsweise nur genau einen Tag gültig sind. Verliert ein Nutzer die Berechtigung, auf Server zuzugreifen genügt es nun, der CA mitzuteilen, dass für diesen Nutzer keine Zertifikate mehr ausgestellt werden sollen und schon hat man seine Zugänge zu allen Rechnern deaktiviert, ohne die Serverkonfiguration selber ändern zu müssen.

Artikel, die hierher verlinken