Anbindung von PKI an OpenSSH mit Monkeysphere

Affenzirkus

SSH gilt seit Jahren als der Standard für verschlüsselte Verbindungen und als Vorzeigeprojekt angewandter Kryptographie. Das Design setzt hierbei auf eine eigene Schlüsselverwaltung, was die Bedienung etwas erschwert. Mit einer PKI-Infrastruktur steigen Benutzerfreundlichkeit und Sicherheit.

Jeder SSH-User, der sich zum ersten Mal mit einem fremden Server verbindet kennt das Problem: Das Programm schlägt Alarm und fordert dazu auf, den Host-Key in Form einer längeren Kombination aus Zahlen und Buchstaben zu bestätigen. Genau genommen sollte dieser peinlich genau geprüft werden, um sicherzustellen, dass es sich auch wirklich um den gewünschten Host handelt. Die Gefahr, Opfer einer "Umleitung" auf den Rechner eines Angreifers zu werden ist ansonsten gegeben. Leider wird dies wohl nur von den wenigsten befolgt, sodass an dieser Stelle bessere Alternativen gefragt sind. Aktuelle OpenSSH-Versionen begegnen dem Problem mit der Anzeige einer Ascii-Grafik, die sich zwar etwas einfacher prüfen lässt, das Grundproblem jedoch nicht behebt.

Die Lösung bestünde (mehr oder weniger einfach) in der Nutzung einer Public Key-Infrastruktur, wie beispielsweise OpenGPG [1] sie bietet. Obwohl entsprechende Projekte wie openssh-gpg [2] existieren, die die Funktionalität per Patch bereitstellen, hat es noch keines zur Aufnahme in die offiziellen OpenSSH-Sourcen [3] geschafft.

Dass es auch ohne Patch geht, zeigt Monkeysphere [4], das keinerlei Änderungen am Code des bereits vorhandenen SSH voraussetzt. Dabei lässt es sich nicht nur zur Authentifizierung der beteiligten Rechner untereinander verwenden, sondern zusätzlich noch zur Verwaltung der Schlüssel der Benutzer im Falle der empfehlenswerten Public-Key-Authentisierung.

Technik

OpenSSH bedient sich zur Absicherung und Verschlüsselung von Verbindungen der Public-Key-Kryptografie: Beim Verbindungsaufbau einigen sich Server und Client zunächst auf beidseitig unterstützte Verschlüsselungsalgorithmen, woraufhin der Schlüsselaustausch beginnt. Hierbei sendet der Server dem Client zunächst den öffentlichen Teil seines Host-Schlüssels, den der Client verifizieren kann. Beim ersten Kontakt mit dem Server kommt es hierbei zur oben angesprochenen Nachfrage, die der Nutzer bestätigen muss. Dbei wird der Schlüssel in der Datei ».ssh/known_hosts« abgelegt, und kommt bei jeder weiteren Verbindung mit dem Server als Datenbasis zum Einsatz. Der Client generiert nun einen Sitzungsschlüssel, verschlüsselt ihn mit dem Public Key des Servers und schickt diesen zurück, da er im folgenden dazu dient, die Daten mit einem symmetrischen Algorithmus zu verschlüsseln. Sollte jemand es schaffen, diesen Schlüssel zu knacken, kann er ebenso die gesamte Kommunikation entschlüsseln. Um dies zu verhindern, sollte man ihn daher in regelmäßigen Abständen austauschen.

Abbildung 1: Die Verschlüsselung erfordert jeweils mehrere Schritte, um einen sicheren Kanal für die Kommunikation herzustellen.

Über den somit abgesicherten Kommunikationskanal findet nun die Authentisierung des Benutzers statt. Diese kann klassisch mit Hilfe von Benutzernamen und Passworten, aber auch mit erneutem Einsatz eines Public Key-Verfahrens ablaufen. Hierbei sendet der Server statt des Host-Schlüssels einen Zufallswert an den Client. Dieser signiert die Nachricht mit seinem privaten Schlüssel. Verfügt der Server über den passenden öffentlichen teil des Schlüssels, kann er die Nachricht mit dessen Hilfe wieder entschlüsseln und somit die Authentizität feststellen. Da ein solcher Schlüssel in den allermeisten Fällen erheblich länger ist als ein Passwort, das ein Normalsterblicher im Kopf behalten kann, ist diese Art des Logins erheblich sicherer.

Was ist verkehrt am Status Quo?

Problematisch ist daher vor allem der erste Kontakt mit dem Server. Zuerst ist der "Fingerprint" des Host-Schlüssels zu prüfen, damit sich niemand für den Server ausgibt. Dies sollte über einen gesicherten Kommunikationsweg wie beispielsweise per Telefon geschehen, findet in der Praxis aber kaum statt. Bei einer Neuinstallation des Servers oder einer Sicherheitslücke, die neue Keys erfordert [5], kann sich dieser Schlüssel durchaus einmal ändern. Dann müssen alle User des Systems darüber informiert werden, und benötigen den neuen, geänderten Fingerprint.

Auch abgelaufene Benutzer-Accounts, die sich über eine Vielzahl von Servern erstrecken, bedeuten Mehrarbeit für den Systemadministrator. Scheidet ein Mitarbeiter aus dem Unternehmen aus, müssen dessen Zugänge schlimmstenfalls auf jedem einzelnen Server gesperrt werden. Mit Hilfe einer zentralen Benutzerverwaltung lässt sich dieses Problem leicht beheben, wobei beispielsweise im Fall eines LDAP-Servers das Problem der Public Keys meist außen vor bleiben dürfte. Eine andere Möglichkeit stellt die Nutzung einer entsprechenden Public Key-Infrastruktur dar: der entsprechende Schlüssel wird dabei an zentraler Stelle für ungültig erklärt.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Systeme mit Vamigru verwalten

Auch wer nur kleine Flotten von Linux-Servern verwaltet, freut sich über Werkzeuge, die ihm diese Arbeit erleichtern. Vamigru tritt mit diesem Versprechen an. Wir verraten, was es leistet und wie Sie es in der eigenen Umgebung in Betrieb nehmen. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite