Remote-Zugriffe mit kurzzeitig gültigen OpenSSH-Zertifikaten
Doppelte Sicherheit
Einmalpasswörter als zusätzlicher Authentifizierungsfaktor eignen sich nicht für die automatisierte Administration vieler Systeme via SSH. Mit temporär gültigen OpenSSH-Zertifikaten lässt sich das praktikabel für große Umgebungen realisieren – auch bei höherem Schutzbedarf.
Administratoren greifen meist über das SSH-Protokoll auf ihre Unix-Systeme zu. Es überträgt die Daten verschlüsselt und bietet je nach SSH-Implementierung und eingesetztem Betriebssystem verschiedene Authentifizierungs- und Autorisierungsmöglichkeiten.
Auf einem großen Teil der Client- und Serversysteme kommt heute das freie OpenSSH zum Einsatz. Das kann man mit Fug und Recht „Hidden Champion“ der Administrationswerkzeuge nennen. Ursprünglich für OpenBSD entwickelt, gibt es OpenSSH in einer portablen Variante für viele Unix-artige Betriebssysteme und insbesondere Linux. Und in jüngster Zeit hat Microsofts PowerShell-Team die Software sogar auf Windows portiert [1].
Konfigurationsoption AuthenticationMethods
Neben einer Anmeldung nur per Passwort existiert eine Variante mit asymmetrischer Verschlüsselung. Beides ist standardmäßig aktiviert, was sich aber in der Konfigurationsdatei sshd_config mit der folgenden Zeile auf die rein schlüsselbasierte Anmeldung einschränken lässt:
AuthenticationMethods publickey
Oder man kann in aktuellen OpenSSH-Versionen die aufeinanderfolgende Nutzung schlüssel- und passwortbasierter Anmeldung erzwingen:
AuthenticationMethods publickey,password
Hierfür erzeugt ein Benutzer zunächst ein asymmetrisches Schlüsselpaar. Anschließend muss man den öffentlichen Key auf dem SSH-Server eindeutig dem User zuordnen. Im einfachsten Fall erledigt dieser das per ssh-copy-id und Passwort selbst. Der Aufruf speichert den öffentlichen Schlüssel in der Datei authorized keys im persönlichen Verzeichnis des Benutzers.
Diese oft beschriebene und gängige Praxis ist einfach durchzuführen und für wenige Benutzer und Systeme meist auch akzeptabel. Bei zunehmender Zahl von Systemen und Benutzern führt ein solches benutzerautonomes Vorgehen rasch zu einer unüberschaubaren Menge autorisierter Schlüssel. Vor allem dann, wenn man lokale Systembenutzerkonten damit versieht und mehrere Clientsysteme die privaten Schlüssel gemeinsam nutzen.
Kontrollierter Zugriff auf AuthorizedKeysFile
Um dies einigermaßen unter Kontrolle zu bringen, ermöglichen Identity-Management-Systeme wie das im Artikel „Gut verteilt“ beschriebene ÆDIR [2] eine kontrollierte Schlüsselverteilung für die von einem zentralen IAM (Identity and Access Management) verwalteten Benutzerkonten.
Hierzu muss man zunächst in der SSH-Server-Konfiguration die Nutzung autorisierter Schlüssel aus vom Benutzer beschreibbaren Dateien unterbinden. Mit der folgenden Beispielkonfiguration liest der OpenSSH-Server die autorisierten Benutzer-Keys nur aus einer nicht vom Benutzer verwalteten Datei: