Öffentliche Schlüssel sind KEINE Zertifikate!

Ich könnte gerade einfach nur schreien. Es ist ein Anwendungsfall aufgetaucht, in dem es notwendig wäre, SSH-Zugänge nicht über eine Passwort-Abfrage, sondern über eine Public-Key-Infrastruktur zu realisieren. Natürlich habe ich mich im Internet auf die Suche danach gemacht, wie man Zertifikate im Zusammenhang mit OpenSSH (wäre die bevorzuge Implementierung) nutzen kann.

Was ich dabei jedoch gefunden habe, spottet jeder Beschreibung. Es scheint so, als ob der Großteil der SSH-Nutzer-Bevölkerung nicht den Unterschied zwischen einem öffentlichen Schlüssel und einem Zertifikat kennt. Diese Unwissenheit reicht dabei von Bloggern, die zu wenig Zeit für Windows haben bis hin zu größeren Projekten wie TortoiseSVN.

Da liest man dann schonmal Dinge wie: "Im Grunde [wird ein] sehr kurzes Passwort durch ein sehr langes ersetzt [...]. Nur wird es dann Zertifikat genannt. Dieses Zertifikat ist in zwei Teile aufgeteilt; in einen privaten und in einen öffentlichen Teil." (wurde inzwischen korrigiert).
Nein, natürlich ist das kein Zertifikat, dass da aus einem öffentlichen und einem privaten Teil besteht - so ein Zertifikat ist idR. immer öffentlich, sonst könnte es niemand auf Echtheit prüfen.

Die Dokumentation von TortoiseSVN hat mich besonders geärgert. Da ich dort auf mehr Fachwissen gehofft hatte, habe ich mich auf den Artikel mit dem Titel "Creating OpenSSH Certificates" gestürzt, nur um dann zu lesen, wie man mit OpenSSH ein RSA-Schlüsselpaar (besteht aus einem öffentlichen und einem privaten Schlüssel) erzeugen kann.

Ein wirklich echtes Zertifikat wird nicht einfach nur erzeugt, sondern es muss eine dritte Partei (eine Certificate Authority) involviert sein, die das Zertifikat erstellt. Dabei kommt dann meist soetwas wie ein Certificate Signing Request zum Einsatz.
Denn was ich eigentlich will ist folgendes: Ich möchte, dass man sich mit einem privaten Schlüssel am SSH-Server anmelden kann, wenn das dazu passende Zertifikat (enthält idR. auch den öffentlichen Schlüssel) auf dem Server hinterlegt ist. Die Crux des Ganzen: Beim versuchten Login müsste der SSH-Server prüfen, ob das Zertifikat tatsächlich von der zugelassenen Zertifizierungsstelle stammt und, ob das Zertifikat überhaupt noch gültig ist! Alles andere würde dazu führen, dass Nutzer sich (potentiell) selbst einen SSH-Login einrichten können und dieser zudem beliebig lange nutzbar bleibt.

Wenn also irgendjemand weiß, wie man OpenSSH mit Zertifikaten (nicht mit einfachen öffentlichen Schlüsseln!) absichern kann, dann würde ich mich über eine Nachricht von demjenigen freuen. 🙂
Update:
Nachdem ich mich gerade noch durch die OpenSSH-Dokumentation gegraben habe, habe ich herausgefunden, dass OpenSSH in der Tat auch mit Zertifikaten arbeiten kann 😀 ! Dafür müssen zum einen die öffentlichen Schlüssel der Nutzer von einer CA signiert werden und zum anderen muss der Daemon sshd so konfiguriert werden (Stichwort "TrustedUserCAKeys"), dass dem CA, der das Zertifikat erstellt hat, auch vom Server vertraut wird.
Zertifizierte Grüße, Kenny

9 Kommentare » Schreibe einen Kommentar

  1. Hi,

    schön das ich nicht der einzige auf der Suche bin ;o) ... Den "TrustedUserCAKeys" habe ich auch schon gefunden, aber nun meine Frage: hast du auch schon die Möglichkeit finden können automatisiert einzelne Schlüssel zu sperren? Thema ist: ich möchte das auf xxx Servern installieren und brauche die Möglichkeit einzelne Schlüssel zu sperren ohne das ich jeden Server einzeln anpacken muss.

    Gruß Sven

    • Zunächst ist mal die Frage, was für dich ein "automatisiertes Sperren". Die Möglichkeit, die sich schon allein aufgrund der Zertifikate ergibt, ist, dass die Schlüssel nach einer gewissen Zeit einfach ablaufen. Aber ich denke mal, dir geht es eher um eine Art Blacklisting von Schlüsseln. Dafür habe ich leider bisher keine Lösung gefunden.

      Eine Lösung, die evtl. machbar wäre, ist folgende: Man könnte einen Netzwerk-Share einrichten, auf dem die signierten Schlüssel der einzelnen User hinterlegt werden. Wenn man auf den einzelnen Servern nun einfach nur Softlinks auf die entsprechenden Zertifikate anlegt, könnte man auf diese Weise eine zentrale Verwaltung der Schlüssel ermöglichen. Das heißt: Bei einer Erneuerung der Zertifikate müssten diese nicht wieder auf den einzelnen Servern verteilt werden und bei eine Sperrung eines Schlüssels müsste man einfach nur das Zertifikat im zentralen Keystore entfernen. Es müsste allerdings geprüft werden, wie der SSH-Demon auf Softlinks generell und auf verwaiste Softlinks im Speziellen reagiert.

      • Ich weiß, der Artikel ist etwas älter, aber mir fiel gerade bei den Stichwörtern "CA", "Zertifikat" und "Sperren" die allseits bekannte Revocation-Liste ein, die jede gute CA natürlich ebenfalls führt.

        Ein guter Dienst vertraut demzufolge nicht einfach nur einer CA, sondern fragt auch die oben genannte Liste ab, um eben sicherzustellen, dass die jeweiligen Zertifikate weiterhin gültig oder eben (vorzeitig) zurückgezogen worden sind. Das macht es im Zuge einer Multi-Server-Umgebung auch einfacher, sich mit Zertifikaten und deren Sperrung herumzuschlagen.

        Bin daher etwas verwundert, dass dieses Feature hier gar nicht zur Sprache kam.

        Automatisierungsaufgaben sind wiederum ein eigenes Thema, aber auch dafür gibt es bereits gute Lösungen.

        • Der Hinweis auf die "TrustedUserCAKeys" sollte ja auch erstmal nur ein Hinweis in die Richtung sein, DASS es möglich ist, SSHD mit Zertifikaten statt mit einfachen Schlüsseln zu füttern (das, was ich gesucht hatte). Dieses Feature kann man durch führen von "RevokedKeys" noch etwas verbessern.

  2. Hm... interessanter Artikel. Aber ich kenne eine andere Definition von "Zertifikat". IMHO ist ein Zertifikat etwas, das einen öffentlichen Schlüssel an eine Entität (eine Person, einen Namen, eine Mailadresse) bindet. Ein Zertifikat kann unterschieben sein. Entweder von einer CA oder in einem web of trust von anderen WoT-Teilnehmern. Es ist aber IMHO nicht so, dass die Unterschrift zwingend zum Zertifikat gehört. Oder wo hast du deine Definition her?

    mfg

    Christian

    • Hallo Christian, natürlich wird durch ein Zertifikat immer auch eine Identität an einen Schlüssel gebunden. Zudem habe ich extra geschrieben, dass der öffentliche Schlüssel "idR." (= in der Regel) im Zertifikat enthalten ist.

      Meine Definition? Habe jetzt einfach mal das Buch "Computer Security Basics" zur Hand genommen. Ich weiß, das Buch ist nur bedingt als Quelle tauglich, aber für ein ordentliches Buch müsste ich jetzt erstmal anfangen, meine Kartons durchzukramen. In dem Buch wird jedenfalls folgende Definition für "Certificates" angeboten:

      In cryptography, a public key certificate [...] is a short document that can be used to verifiy that a public key belongs to an individual. The certificate uses a digital certificate to bind together a public key with information such as the name of the person, an organization or address information. A certificate usually follows the ITU-T X.509 standard, which includes the following:
      * The public key being signed.
      * [...]

      In dem hier vorliegenden Fall ist die Information, dass Schlüssel X zu Person Y gehört lustigerweise garnicht das Wichtigste - die Information, dass CA Z den Schlüssel X kennt, ist in diesem Szenario viel spannender. 🙂

      • Die von dir gepostete Definition deckt sich ja in Etwa mit meiner. Aber du hast natürlich Recht, für das von dir beschriebene Szenario ist die Signatur durch eine (interne oder externe) CA fast wichtiger.

        mfg

        Christian

  3. Hi,
    im Grunde hast Recht, es ist wirklich kein (aber nur wenn man es absolut genau nimmt) Zertifikat. Habe es in meimem Artikel auf Schlüsselpaar abgeändert und hoffe auf wohlwollendes Entgegenkommen 🙂 Danke.
    Gruss, Marzl

    • Habe hinter das Zitat geschrieben, dass du den Text inzwischen korrigiert hast und dabei auf deinen Kommentar hier verlinkt. Hope it helps.

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.