SSH-Schlüssel vs. SSH-Zertifikate: Was der Unterschied wirklich bedeutet

SSH-Schlüssel und SSH-Zertifikate authentifizieren Benutzer und Systeme zwar beide mittels Public-Key-Kryptografie , basieren aber auf grundlegend unterschiedlichen Vertrauensmodellen. SSH-Schlüssel schaffen Vertrauen, indem sie autorisierte öffentliche Schlüssel in der Datei `authorized_keys` jedes Servers ablegen. SSH-Zertifikate hingegen nutzen eine vertrauenswürdige Zertifizierungsstelle (CA) , um Identitäten zu verifizieren und zeitlich begrenzten Zugriff zentral zu gewähren. Dieser Unterschied wirkt sich auf jede Phase des Lebenszyklus von Anmeldeinformationen aus: die Gewährung, Verwaltung, Überprüfung und den Entzug von Zugriffsrechten, insbesondere bei wachsenden Umgebungen. Empfohlene Vorgehensweise: SSH-Schlüssel sollten in Umgebungen, in denen der Einsatz von Schlüsseln praktikabel ist, zentral verwaltet und rotiert werden. Für Umgebungen, in denen der Schlüsselbestand die manuelle Verwaltung übersteigt, sollte die zertifikatsbasierte Authentifizierung evaluiert werden.

Kurzantwort: SSH-Schlüssel vs. SSH-Zertifikate

SSH-Schlüssel: Jeder Server vertraut unabhängig den in seiner Datei `authorized_keys` aufgeführten öffentlichen Schlüsseln. Diese Schlüssel haben kein Ablaufdatum und es gibt keine zentrale Datenbank. Der Zugriff bleibt bestehen, bis er manuell von jedem Server entfernt wird. SSH-Zertifikate: Der Server vertraut einer Zertifizierungsstelle (CA). Die CA garantiert die Identität von Zertifikaten durch Signierung mit Gültigkeitsdauer, Prinzipalnamen und optionalen Einschränkungen. Der Zugriff erlischt automatisch, sobald die Gültigkeitsdauer abgelaufen ist. Der Unterschied zwischen den beiden Ansätzen liegt nicht in der kryptografischen Stärke, sondern darin, wie sich der Zugriff im Laufe der Zeit verändert, wenn Teams, Systeme und Anmeldeinformationen zunehmen. Die vollständige Übersicht über die SSH-Schlüsselverwaltung finden Sie unter SSH-Schlüsselverwaltungs-Compliance . Informationen zum Rotationsrahmen finden Sie unter Entwurf einer effektiven SSH-Schlüsselrotationsrichtlinie.

Das Akkumulationsproblem: Warum der Unterschied wichtig ist

Die Auswirkungen dieser unterschiedlichen Vertrauensmodelle auf den Betrieb werden mit zunehmender Größe der Umgebungen deutlich. Das Problem tritt nicht als einmaliges Ereignis auf, sondern häuft sich an. Ein Entwickler tritt dem Unternehmen bei, und sein Schlüssel wird auf einem Dutzend Servern hinzugefügt. Ein externer Mitarbeiter beendet sein Projekt, und sein Schlüssel wird nicht entfernt, da niemand nachverfolgt hat, auf welchen Servern er sich befand. Automatisierungspipelines erzeugen Schlüsselpaare, die die Pipelines, für die sie entwickelt wurden, überdauern. Drei Jahre später befinden sich Hunderte von Schlüsseln in der gesamten Serverinfrastruktur, ohne dass ein verlässliches Verzeichnis ihrer Eigentümer existiert.

Branchenstudien zufolge empfinden 57 % der Unternehmen die Verwaltung von SSH-Schlüsseln als aufwendig und schwierig. Obwohl das Bewusstsein dafür gestiegen ist, bleibt das zugrundeliegende operative Risiko unkontrollierter Schlüssel bestehen, unabhängig davon, wie gut das Problem erkannt wird. Die Schwierigkeit, dies frühzeitig zu erkennen, liegt darin, dass zunächst keine offensichtlichen Ausfälle auftreten. Server reagieren, Pipelines laufen, Bereitstellungen werden abgeschlossen. Das Zugriffsproblem bleibt unsichtbar, bis es sich als Sicherheits- oder Compliance-Vorfall bemerkbar macht.

Hier wird die Unterscheidung zwischen SSH-Schlüsseln und SSH-Zertifikaten wichtig. Beide bieten eine starke Authentifizierung, aber ihre Vertrauensmodelle bestimmen, wie dieses Vertrauen im Laufe der Zeit aufrechterhalten, erweitert und widerrufen wird. Das Verständnis der strukturellen Unterschiede ermöglicht es Organisationen, das richtige Modell für ihre Umgebung und ihren Reifegrad der Governance auszuwählen.

Was sind SSH-Schlüssel?

Ein SSH- Schlüssel ist ein kryptografisch verknüpftes Paar: ein privater und ein öffentlicher Schlüssel, die gemeinsam als zusammengehöriges Set generiert werden. Sie dienen einem einzigen Zweck: der Identitätsprüfung, ohne ein Passwort über das Netzwerk zu senden.

Der private Schlüssel verbleibt auf dem Rechner, auf dem er erstellt wurde. Er darf niemals kopiert, weitergegeben oder übertragen werden. Er ist die einzige Datei, die eine Authentifizierungsanfrage des Servers beantworten kann, und seine Sicherheit bildet die Grundlage des gesamten Vertrauens.

Der öffentliche Schlüssel wird an die Server verteilt, auf denen Zugriff benötigt wird. Auf jedem Server wird er in der Datei `authorized_keys` gespeichert (typischerweise `~/.ssh/authorized_keys` für das jeweilige Benutzerkonto). Diese Datei ist eine Liste: Jede Zeile enthält einen öffentlichen Schlüssel, der jeweils eine Entität repräsentiert, die der Server authentifiziert.

Die Sicherheit beruht auf asymmetrischer Kryptographie : Der private Schlüssel erzeugt eine kryptografische Signatur , die nur mit dem zugehörigen öffentlichen Schlüssel verifiziert werden kann. Die Kenntnis des einen Schlüssels erlaubt nicht die Ableitung des anderen; eine gültige Signatur kann nur vom Inhaber des privaten Schlüssels erzeugt werden.

So funktioniert die SSH-Schlüsselauthentifizierung

Die Authentifizierungssequenz stellt die Identität her, ohne den privaten Schlüssel zu übertragen:

1. Der öffentliche Schlüssel des Benutzers wird in der Datei authorized_keys auf dem Zielserver abgelegt (entweder durch einen Administrator, durch den Benutzer, falls dieser über Serverzugriff verfügt, oder durch automatisierte Bereitstellung).
2. Der Benutzer initiiert eine Verbindung. SSH Der Client signalisiert, welchen öffentlichen Schlüssel er zur Authentifizierung verwenden möchte.
3. Der Server prüft seine Datei authorized_keys. Ist der übermittelte öffentliche Schlüssel vorhanden und für das Zielbenutzerkonto zulässig, fährt der Server mit der Authentifizierung fort.
4. Der Client signiert die Authentifizierungsanfrage mit seinem privaten Schlüssel und sendet die signierte Anfrage an den Server. Der private Schlüssel verlässt niemals den Client.
5. Der Server überprüft die Signatur mithilfe des gespeicherten öffentlichen Schlüssels. Eine gültige Signatur bestätigt, dass der Client über den zugehörigen privaten Schlüssel verfügt. Die Authentifizierung ist erfolgreich.

Das Vertrauensmodell: Der Server vertraut dem SSH-Schlüssel, weil dieser in der Datei „authorized_keys“ aufgeführt ist. Dieses Vertrauen ist zeitlich unbegrenzt und wird nicht zentral gespeichert. Es bleibt so lange bestehen, bis der Schlüssel manuell auf jedem Server, auf dem er eingesetzt ist, aus dieser Datei entfernt wird.

Die operativen Herausforderungen der SSH-Schlüsselverwaltung

Der Authentifizierungsprozess selbst ist sicher. Die Herausforderungen ergeben sich daraus, wie Vertrauen in großem Umfang aufgebaut und aufrechterhalten werden kann:

• Jeder Server verwaltet seine eigene authorized_keys-Datei. Jeder öffentliche Schlüssel, der Zugriff benötigt, muss auf jedem Server einzeln hinzugefügt, aktualisiert oder entfernt werden.
• SSH-Schlüssel haben kein eingebautes Ablaufdatum. Ein öffentlicher Schlüssel bleibt so lange vertrauenswürdig, bis er manuell von jedem Server entfernt wird, auf dem er installiert ist.
• Ohne eine zentrale InventarOrganisationen haben Schwierigkeiten festzustellen, wem ein Schlüssel gehört, warum er eingesetzt wurde, ob er noch verwendet wird und ob er weiterhin existieren sollte.
• Schlüssel, die für temporäre Projekte, Auftragnehmer oder Automatisierungsabläufe erstellt wurden, können lange nach Beendigung ihres Zwecks aktiv bleiben und so die Angriffsfläche unbemerkt vergrößern.

Diese Einschränkungen sind keine Schwächen der SSH-Kryptografie. Sie sind eine Folge des dezentralen Vertrauensmodells, in dem jeder Server unabhängig entscheidet, welchen öffentlichen Schlüsseln er vertraut. Mit zunehmender Größe von Umgebungen suchen Unternehmen nach Möglichkeiten, Vertrauensentscheidungen zu zentralisieren, den manuellen Verwaltungsaufwand zu reduzieren und die Transparenz zu verbessern. SSH-Zertifikate wurden entwickelt, um diese betrieblichen Herausforderungen zu bewältigen. Weiterführende Informationen zur Verwaltung von SSH-Schlüsseln in großem Umfang finden Sie unter „ Wie die SSH-Schlüsselverwaltung die Sicherheit stärkt“ und „SSH-Schlüssel mit HSMs sichern“.

Was sind SSH-Zertifikate?

Ein SSH-Zertifikat ist ein öffentlicher Schlüssel, der von einer vertrauenswürdigen Zertifizierungsstelle (CA) signiert wurde. Die Signatur der CA verknüpft Identitäts- und Zugriffsinformationen mit dem Schlüssel und erzeugt so eine verifizierbare Anmeldeinformation mit integrierter Gültigkeitsdauer. Im Gegensatz zu einem eigenständigen öffentlichen Schlüssel ohne Eigentümerinformationen enthält ein SSH-Zertifikat Folgendes:

• Schlüssel-ID: Eine beliebige Zeichenfolge, die beim Signieren vergeben wird und das Zertifikat in Protokollen und Prüfaufzeichnungen identifiziert. Organisationen verwenden Benutzernamen, E-Mail-Adressen, Mitarbeiter-IDs oder Ticketnummern.
• Liste der Schulleiter: Die Identitäten, die das Zertifikat vertreten darf. Bei Benutzerzertifikaten entsprechen die Prinzipale Betriebssystembenutzernamen wie ubuntu, ec2-user oder admin.
• Gültigkeitszeitraum: Ein Gültigkeitsende- und Gültigkeitsbeginn-Zeitstempel (Unix-Zeitstempel) wird während der Authentifizierung erzwungen. Liegt die aktuelle Zeit außerhalb dieses Zeitfensters, wird das Zertifikat automatisch abgelehnt.
• Erweiterungen: Funktionen wie permit-pty (Terminalzugriff), permit-Portweiterleitung oder permit-Agentweiterleitung.
• Wichtige Optionen: erzwungene Einschränkungen, wie z. B. die Beschränkung des Zertifikats auf bestimmte Quell-IP-Adressen oder die Begrenzung der Sitzung auf einen einzigen Befehl.
• CA-Unterschrift: Die kryptografische Signatur der Zertifizierungsstelle schützt alle oben genannten Elemente vor Manipulationen, ohne das Zertifikat ungültig zu machen.

Das von OpenSSH verwendete SSH-Zertifikatformat unterscheidet sich vom X.509- Format für HTTPS. Es handelt sich um ein speziell entwickeltes Format, das in der OpenSSH-Spezifikation PROTOCOL.certkeys definiert ist. Die Zertifizierungsstelle (CA) selbst ist lediglich ein SSH-Schlüsselpaar an einem geschützten Ort: Ihr privater Schlüssel signiert Benutzer- und Hostzertifikate; ihr öffentlicher Schlüssel wird einmalig an jeden Server verteilt. Ab diesem Zeitpunkt kann jeder Server, der der CA vertraut, von dieser CA signierte Zertifikate authentifizieren.

So funktioniert die SSH-Zertifikatsauthentifizierung

Die Authentifizierungssequenz unterscheidet sich von der schlüsselbasierten Authentifizierung in der Art und Weise, wie Vertrauen hergestellt wird. Anstatt zu prüfen, ob der Verbindungsschlüssel auf dem jeweiligen Server aufgeführt ist, prüft der Server, ob das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde.

1. Es wird ein CA-Schlüsselpaar generiert und dessen öffentlicher Schlüssel einmalig mithilfe der Direktive „TrustedUserCAKeys“ in der Datei „sshd_config“ an jeden Server verteilt. Dies ist ein einmaliger Einrichtungsschritt pro Server; beim Hinzufügen oder Entfernen von Benutzern sind keine Änderungen erforderlich.
2. Benötigt ein Benutzer Zugriff, wird sein öffentlicher Schlüssel zur Signierung an die Zertifizierungsstelle (CA) übermittelt. Die CA signiert ihn mit ihrem privaten Schlüssel und sendet ein Zertifikat zurück, das den Schlüssel des Benutzers, seine Identität, die Berechtigungsstufen und den Gültigkeitszeitraum enthält. Der private Schlüssel des Benutzers bleibt unverändert.
3. Der Benutzer initiiert eine Verbindung. Der SSH-Client präsentiert das Benutzerzertifikat und beweist den Besitz des privaten Schlüssels durch Signierung der Authentifizierungsanfrage.
4. Der Server überprüft die CA-Signatur auf dem Zertifikat mithilfe des CA-öffentlichen Schlüssels, den er bereits in Schritt 1 gespeichert hat.
5. Der Server prüft, ob der Zertifikatstyp für die Benutzerauthentifizierung korrekt ist.
6. Der Server prüft, ob die aktuelle Zeit innerhalb des Gültigkeitszeitraums liegt.
7. Der Server prüft, ob mindestens ein Prinzipal im Zertifikat mit dem Zielbenutzerkonto übereinstimmt.
8. Wenn alle Prüfungen erfolgreich sind, verifiziert der Server die Client-Signatur. Eine gültige Signatur bestätigt, dass der Client den entsprechenden privaten Schlüssel besitzt. Der Zugriff wird gewährt.
9. Nach Ablauf der Gültigkeitsdauer verliert das Zertifikat automatisch seine Gültigkeit. Der Benutzer muss ein neues, von der Zertifizierungsstelle signiertes Zertifikat anfordern, um wieder Zugriff zu erhalten. Der private Schlüssel verlässt den Client zu keinem Zeitpunkt.

Der strukturelle Unterschied zur schlüsselbasierten Authentifizierung besteht darin, dass der Server keinen bereits vorhandenen Datensatz des Benutzers benötigt. Das Vertrauen wird von der Zertifizierungsstelle (CA) und nicht von einer Datei auf jedem einzelnen Server generiert.

SSH-Schlüssel vs. SSH-Zertifikate: Ein direkter Vergleich

Abmessungen	SSH-Schlüssel	SSH-Zertifikate
Vertrauensmodell	Jeder Server vertraut direkt den einzelnen öffentlichen Schlüsseln, die in seiner Datei authorized_keys aufgeführt sind.	Jeder Server ist so konfiguriert, dass er einer oder mehreren Zertifizierungsstellen vertraut und von diesen Zertifizierungsstellen signierte Zertifikate akzeptiert.
Anmeldeinformationsformat	Eigenständiger öffentlicher Schlüssel	Öffentlicher Schlüssel mit signierten Metadaten und CA-Signatur
Identitätsinformationen.	Optionales Kommentarfeld; wird bei der Authentifizierung nicht überprüft.	Signierte Schlüssel-ID und Prinzipale sind im Zertifikat eingebettet und werden während der Authentifizierung verifiziert.
Ablauf	Keine eingebaute Ablaufzeit; der Zugriff bleibt gültig, bis der Schlüssel manuell von jedem Server entfernt wird.	Die integrierte Gültigkeitsdauer wird während der Authentifizierung durchgesetzt; das Zertifikat wird beim Schließen des Fensters automatisch abgelehnt.
Zugriffsbereitstellung	Öffentliche Schlüssel müssen an jeden Server verteilt werden, auf den Zugriff erforderlich ist.	Die Server vertrauen der Zertifizierungsstelle; Benutzer erhalten von der Zertifizierungsstelle ausgestellte Zertifikate; beim Hinzufügen von Benutzern erfolgen keine serverseitigen Änderungen.
Zugriffsentfernung	Öffentliche Schlüssel müssen von jedem Server entfernt werden, dem sie vertraut werden; leicht zu übersehende Server	Das Zertifikat darf nicht erneuert werden; der Zugriff erlischt automatisch. Ein vorzeitiger Widerruf über eine Schlüsselsperrliste (KRL) ist möglich, erfordert jedoch die Verteilung der KRL an alle Server.
Rotation	Erfordert die Generierung eines neuen Schlüsselpaares, die Verteilung des neuen öffentlichen Schlüssels und die Entfernung des alten Schlüssels von allen Servern.	Es wird ein neues Zertifikat ausgestellt; das zugrunde liegende Schlüsselpaar kann wiederverwendet werden, sofern die Organisationsrichtlinien dies zulassen.
Serververwaltung	Erfordert die Pflege der authorized_keys-Einträge auf allen Servern für alle Benutzer	Erfordert die einmalige Pflege der CA-Vertrauenskonfiguration pro Server und die Verwaltung der Zertifikatsausstellung.
Überprüfbarkeit	Protokolle zeigen wichtige Fingerabdrücke; die Zuordnung von Besitzverhältnissen erfordert externe Datensätze; die Zuordnung zu einzelnen Personen ist schwierig, wenn Schlüssel geteilt werden.	Zertifikate enthalten signierte Identitätsattribute, Schlüssel-IDs und Seriennummern, die die Rückverfolgbarkeit direkt in den Authentifizierungsprotokollen verbessern.
Skalierbarkeit	Der Verwaltungsaufwand steigt linear mit der Anzahl der Benutzer, Schlüssel und Server.	Der Managementaufwand verlagert sich hin zur zentralisierten Zertifikatsausstellung und CA-Governance; das Hinzufügen von Benutzern erfordert keine Änderungen pro Server.
Infrastrukturanforderungen	Keine CA-Infrastruktur erforderlich	Erfordert ein CA-Schlüsselpaar, einen Zertifikatsausstellungsprozess und die Verteilung des CA-Vertrauens auf alle Server.
Compliance-Haltung	Erfordert aktives Bestands-, Rotations- und Widerrufsmanagement, um die Anforderungen der Zugriffskontrollrahmen zu erfüllen.	Integrierte Ablauf- und zentrale Ausstellungsprotokolle liefern automatisch Nachweise für die Einhaltung der Vorschriften; kurzlebige Zertifikate reduzieren den Aufwand für die manuelle Widerrufung.
Typischer Anwendungsfall	Kleine bis mittlere Umgebungen, statische Zugriffsbeziehungen, einfache Bereitstellungen mit aktiver Schlüsselverwaltung	Großflächige Umgebungen, dynamisches Zugriffsmanagement, zentralisierte Identitätsverwaltung oder Organisationen, in denen der Bestand an SSH-Schlüsseln die Kapazität für die manuelle Verwaltung überschritten hat

Lebenszyklus-Besitz: SSH-Schlüssel vs. SSH-Zertifikate

Stadium des Lebenszyklus	SSH-Schlüssel: Wer ist verantwortlich?	SSH-Zertifikate: Wer ist verantwortlich?
Generation	Benutzer oder Automatisierungssystem; erfordert die Durchsetzung von Richtlinien bezüglich Algorithmus und Schlüssellänge	Der Nutzer übermittelt den öffentlichen Schlüssel an die Zertifizierungsstelle; die Zertifizierungsstelle signiert und sendet das Zertifikat zurück; Algorithmus und Gültigkeit werden durch die Richtlinien der Zertifizierungsstelle sichergestellt.
Vertrieb	Ein Administrator oder ein automatisiertes Tool fügt den öffentlichen Schlüssel in die Datei „authorized_keys“ jedes autorisierten Servers ein.	Der Benutzer erhält das Zertifikat; auf den Servern sind keine Änderungen erforderlich; der öffentliche Schlüssel der Zertifizierungsstelle wurde bereits verteilt.
Überwachung	Sitzungsprotokolle zeigen wichtige Fingerabdrücke; die Zuordnung von Besitzverhältnissen erfordert ein externes Inventar.	Zertifikatsschlüssel-ID und Seriennummer erscheinen in den Protokollen; die Identität lässt sich direkt aus dem Protokoll zurückführen.
Rotation	Neues Schlüsselpaar generiert; neuer öffentlicher Schlüssel auf allen Servern bereitgestellt; alter Schlüssel von allen Servern entfernt	Neues Zertifikat ausgestellt; vorheriges Zertifikat läuft regulär ab; keine serverseitigen Änderungen an authorized_keys erforderlich
Widerruf bei Abreise	Der öffentliche Schlüssel muss identifiziert und von allen Servern entfernt werden; die Lücke zwischen Entfernung und Abschluss stellt ein Compliance-Risiko dar.	Die Ausstellung von Zertifikaten an den ausgeschiedenen Benutzer wird eingestellt; das bestehende Zertifikat läuft innerhalb des Gültigkeitszeitraums ab; KRL-Eintrag für sofortigen vorzeitigen Widerruf.
Prüfnachweis	Generiert aus Sitzungsprotokollen und externem Schlüsselinventar; erfordert Korrelation	Das CA-Ausstellungsprotokoll ermöglicht die direkte Zuordnung; das Gültigkeitsfenster liefert automatisch den Nachweis des zeitlich begrenzten Zugriffs.

Was sollten Sie verwenden: SSH-Schlüssel oder SSH-Zertifikate?

Keiner der beiden Ansätze ist generell überlegen. Die richtige Wahl hängt von der Größe des Umfelds, dem Reifegrad der Governance und der operativen Kapazität ab:

• SSH-Schlüssel sind praktisch und sicher In kleinen bis mittleren Umgebungen, in denen der Schlüsselbestand bekannt ist, die Besitzer dokumentiert sind, die Schlüsselrotation planmäßig erfolgt und die Sperrung bei Ausscheiden umgehend durchgeführt wird, sind die Governance-Anforderungen für SSH-Schlüssel in diesem Umfang mit einer entsprechenden SSH-Schlüsselverwaltungsplattform handhabbar.
• SSH-Zertifikate werden vorteilhaft wenn: die Organisation nicht in der Lage ist, auf Anfrage ein aktuelles Inventar aller SSH-Schlüssel zu erstellen; die Verwaltung von authorized_keys-Dateien auf Hunderten von Servern zu Inkonsistenzen führt; die Zeitspanne zwischen dem Ausscheiden eines Mitarbeiters und dem vollständigen Entzug der SSH-Berechtigung länger als akzeptabel ist; Compliance-Audits Feststellungen über verwaiste oder nicht rotierte Schlüssel ergeben; oder die Umgebung schneller skaliert, als die manuelle Schlüsselverwaltung mithalten kann.
• Der Übergang kann schrittweise erfolgen: Server können während der Migration sowohl herkömmlichen öffentlichen Schlüsseln als auch der Zertifizierungsstelle gleichzeitig vertrauen. Das bedeutet, dass bestehende Schlüssel weiterhin funktionsfähig bleiben, während die zertifikatsbasierte Authentifizierung eingeführt wird, was eine schrittweise und risikoarme Migration ermöglicht.

Für Organisationen, die auf Zertifikate oder ephemere Zugriffsmodelle umsteigen, siehe Transform Static SSH Keys into Short-Lived Workload Identities für das Migrationsframework und den SPIFFE/SPIRE-Workload-Identitätsansatz für Dienstkonten.

Auslöser für Rotation und Widerruf

• Ausscheiden oder Funktionswechsel des Mitarbeiters: Bei SSH-Schlüsseln sollte der öffentliche Schlüssel umgehend von allen Servern entfernt werden; bei SSH-Zertifikaten sollte die Ausstellung von Zertifikaten eingestellt und ein KRL-Eintrag für den sofortigen vorzeitigen Widerruf aller gültigen Zertifikate hinzugefügt werden.
• Verdacht auf Kompromittierung oder bestätigte Kompromittierung: Bei SSH-Schlüsseln: Widerrufen Sie diese auf allen Servern und generieren Sie einen Ersatz; bei SSH-Zertifikaten: Fügen Sie einen KRL-Eintrag hinzu und stellen Sie diese von der Zertifizierungsstelle neu aus.
• Algorithmus veraltet: Alle Schlüssel und Zertifikate, die veraltete Algorithmen (DSA, RSA-1024) verwenden, müssen ersetzt werden. Einen Vergleich der Algorithmen finden Sie hier. Vergleich von SSH-Schlüsseln: RSA, DSA, ECDSA oder EdDSA.
• Systemstilllegung: Entfernen Sie alle SSH-Schlüsselautorisierungen für außer Betrieb genommene Systeme; aktualisieren Sie bei Zertifikatsbereitstellungen die AuthorizedPrincipalsFile auf den verbleibenden Systemen.
• Kompromittierung des CA-Privatschlüssels: Bei der Zertifikatsbereitstellung ist dies der kritischste Vorgang: Der öffentliche Schlüssel der Zertifizierungsstelle muss auf jedem Server ersetzt werden, und alle zuvor ausgestellten Zertifikate verlieren ihre Gültigkeit. Schützen Sie die privaten Schlüssel der Zertifizierungsstelle in HSMs, um dieses Szenario zu verhindern.

Reaktion auf Sicherheitsvorfälle: Kompromittierung von SSH-Schlüsseln vs. SSH-Zertifikaten

• Kompromittierter SSH-Schlüssel: Identifizieren Sie alle Server, deren öffentlicher Schlüssel in authorized_keys enthalten ist (erfordert eine Inventarisierung); entfernen Sie den öffentlichen Schlüssel von jedem Server; generieren Sie ein neues Schlüsselpaar; verteilen Sie den neuen öffentlichen Schlüssel an die autorisierten Server; überprüfen Sie, ob die Authentifizierung mit dem neuen Schlüssel funktioniert; protokollieren Sie alle Aktionen mit Zeitstempeln als Nachweis der Compliance.
• Kompromittiertes SSH-Zertifikat: Die Seriennummer des Zertifikats wird der KRL hinzugefügt; die aktualisierte KRL wird umgehend an alle Server verteilt; das Zertifikat wird beim nächsten Verbindungsversuch abgelehnt; nach Behebung des Fehlers bei der Anmeldeinformationsverarbeitung wird ein neues Zertifikat ausgestellt; falls der zugrunde liegende private Schlüssel kompromittiert ist, wird auch das Schlüsselpaar rotiert.
• Kompromittierter CA-Privatschlüssel (Zertifikatbereitstellungen): Generieren Sie ein neues CA-Schlüsselpaar; verteilen Sie den neuen öffentlichen CA-Schlüssel an alle Server (und ersetzen Sie dabei den alten Eintrag „TrustedUserCAKeys“); stellen Sie für alle Benutzer neue Zertifikate von der neuen CA aus; der alte öffentliche CA-Schlüssel kann von den Servern entfernt werden, sobald alle Benutzer zur neuen CA migriert wurden. Dies ist der kritischste Fall; schützen Sie die privaten CA-Schlüssel in HSMs, um ihn zu verhindern.

Wie Verschlüsselungsberatung helfen kann

Wir von Encryption Consulting verstehen die Herausforderungen, denen sich Unternehmen bei der Verwaltung von SSH-Schlüsseln in großem Umfang gegenübersehen. SSH Secure bietet umfassende Sicherheit über den gesamten Schlüssellebenszyklus, zentrale Transparenz und HSM-gestützten Schutz sowohl für SSH-Schlüssel- als auch für Zertifikatsumgebungen:

1. Zentralisierte Darstellung von Sichtbarkeit und Verantwortlichkeiten

Die agentenbasierte und agentenlose Erkennung lokalisiert jeden SSH-Schlüssel auf Servern und Benutzerrechnern. Alle Schlüssel werden in einem einheitlichen Inventar mit Eigentümer- und Nutzungsdetails gespeichert, wodurch verwaiste Schlüssel vermieden und die vollständige Nachvollziehbarkeit in der gesamten Umgebung gewährleistet wird.

2. Automatisierte Orchestrierung des Schlüssellebenszyklus

SSH Secure automatisiert den gesamten Schlüssellebenszyklus: sichere Generierung, richtlinienbasierte Rotation und Widerruf. Ephemere, sitzungsgebundene Schlüssel laufen bei sensiblen Operationen automatisch ab, wodurch das Prinzip der minimalen Berechtigungen durchgesetzt und sichergestellt wird, dass Schlüssel nicht über ihren vorgesehenen Verwendungszweck hinaus bestehen bleiben.

3. HSM-integrierter Schutz

Alle privaten Schlüssel werden innerhalb von HSMs generiert und gespeichert , wobei RSA-4096, ECDSA und Ed25519 zum Einsatz kommen. Die nicht exportierbare, manipulationssichere Speicherung der privaten Schlüssel verhindert deren Extraktion selbst bei einer Kompromittierung des Host-Betriebssystems.

4. Richtlinienbasierte Steuerung wichtiger operativer Tätigkeiten

Alle wichtigen Abläufe werden durch richtlinienbasierte Kontrollen durchgesetzt, um Konsistenz im gesamten System zu gewährleisten, manuelle Fehler zu reduzieren und die Einhaltung regulatorischer Anforderungen oder interner Governance-Modelle sicherzustellen.

5. Kontinuierliche Überwachung, Prüfung und Bereitschaft zur Einhaltung von Vorschriften

Echtzeitüberwachung mit detaillierter Ereignisprotokollierung, Splunk- oder Grafana Loki-Integration, herunterladbaren Audit-Logs und Compliance-Berichten, die Sicherheitsteams einen klaren Einblick in die Schlüsselnutzung und den allgemeinen Sicherheitsstatus geben.

Fazit

SSH-Schlüssel und SSH-Zertifikate lösen dasselbe Authentifizierungsproblem auf kryptografischer Ebene. Beide beweisen die Identität, ohne ein Passwort zu übertragen. Der Unterschied liegt nicht in der Stärke der Kryptografie, sondern im zeitlichen Verlauf des Zugriffs. Ein Schlüssel, der vor drei Jahren von einem ehemaligen Mitarbeiter auf einem Server hinterlegt wurde, ist heute genauso gültig wie am Tag seiner Hinterlegung. Der Server kann dies nicht feststellen. Das ist kein Fehler des Schlüssels, sondern eine Folge des dezentralen Vertrauensmodells, das auf Einfachheit ausgelegt ist.

Die Lücke liegt in der Governance über den gesamten Lebenszyklus von Anmeldeinformationen hinweg. Für Organisationen, in denen der SSH-Schlüsselbestand bekannt ist, die Inhaberschaft dokumentiert ist und Rotation und Widerruf konsequent durchgesetzt werden, bleiben SSH-Schlüssel eine sichere und praktikable Wahl. Für Organisationen, deren Bestand die manuelle Verwaltung übersteigt, bieten SSH-Zertifikate strukturelle Vorteile: integriertes Ablaufdatum, zentralisierte Ausstellungsprotokolle und die Eliminierung der Verwaltung von authorized_keys pro Server. Die Stärkung der SSH-Schlüssel-Governance durch zentrale Ermittlung, Inhaberzuordnung, richtlinienbasierte Rotation und zeitnahen Widerruf ist der unmittelbarste und praktischste Schritt zur Sicherung privilegierter Zugriffe, unabhängig davon, ob eine Migration zu Zertifikaten geplant ist. Weiterführende Informationen finden Sie unter „SSH Key Management Compliance“ , „ Why Never-Expiring SSH Keys Are a Security Risk“ und „ Transform Static SSH Keys into Short-Lived Workload Identities“.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen SSH-Schlüsseln und SSH-Zertifikaten?

SSH-Schlüssel stellen Vertrauen her, indem sie den öffentlichen Schlüssel des Benutzers in der Datei `authorized_keys` des Servers speichern. Dieses Vertrauen ist zeitlich unbegrenzt und wird nicht zentral gespeichert; es bleibt bestehen, bis der Schlüssel manuell von jedem Server entfernt wird. SSH-Zertifikate verwenden eine vertrauenswürdige Zertifizierungsstelle (CA) zur Identitätsprüfung; der Server vertraut der CA, das Zertifikat hat ein integriertes Gültigkeitsfenster, und der Zugriff erlischt automatisch nach Ablauf dieses Fensters.

Was soll ich verwenden: SSH-Schlüssel oder SSH-Zertifikate?

SSH-Schlüssel sind praktisch, wenn der Schlüsselbestand bekannt, die Besitzverhältnisse dokumentiert und die Governance aktiv ist. SSH-Zertifikate sind vorteilhaft, wenn der Schlüsselbestand die manuelle Nachverfolgung übersteigt, der Widerruf langsam ist oder Compliance-Audits Beanstandungen ergeben. Der Übergang kann schrittweise erfolgen: Server können während der Migration beiden Modellen gleichzeitig vertrauen.

Laufen SSH-Zertifikate automatisch ab?

Ja. SSH-Zertifikate enthalten ein Gültigkeitsfenster (mit Zeitstempeln für „gültig bis“ und „gültig bis“), das während der Authentifizierung durchgesetzt wird. Liegt die aktuelle Zeit außerhalb dieses Fensters, wird das Zertifikat unabhängig von zuvor bestehendem Vertrauen abgelehnt. SSH-Schlüssel haben kein integriertes Ablaufdatum; sie bleiben vertrauenswürdig, bis sie manuell aus der Datei „authorized_keys“ auf jedem Server entfernt werden.

Wie kann man ein SSH-Zertifikat vor dessen Ablauf widerrufen?

Über eine Schlüsselsperrliste (KRL): Der CA-Administrator fügt die Zertifikatsseriennummer oder den Schlüsselfingerabdruck zur KRL hinzu; jeder Server prüft die KRL über die sshd_config-Direktive `RevokedKeys`. Einschränkung: Die KRL muss an alle Server verteilt werden, bevor ein Sperrvorgang wirksam wird. Kurzlebige Zertifikate verringern dieses Problem: Ein Zertifikat mit einer Gültigkeit von acht Stunden läuft ab, bevor die meisten Sperrvorgänge erforderlich werden.

Welche Betriebskosten entstehen für die Bereitstellung einer SSH-Zertifizierungsstelle?

Einmalig: CA-Schlüsselpaar generieren; öffentlichen CA-Schlüssel über TrustedUserCAKeys an alle Server verteilen. Privaten CA-Schlüssel in einem HSM für Hochsicherheitsumgebungen schützen. Laufend: Zertifikatsausstellung verwalten (Integration mit Identitätsanbietern, Festlegung von Principals und Gültigkeitszeiträumen); CA-Schlüsselrotation über mehrere Jahre; KRL-Management für frühzeitigen Widerruf. Im Gegenzug: Wegfall der serverseitigen Verwaltung von authorized_keys für alle zertifizierten Benutzer.

Sind SSH-Zertifikate dasselbe wie TLS-Zertifikate?

Nein. SSH-Zertifikate verwenden das OpenSSH-PROTOCOL.certkeys-Format (SSH-spezifisch), nicht X.509 (für TLS/HTTPS). Beide verwenden eine Zertifizierungsstelle (CA), die für einen öffentlichen Schlüssel bürgt, aber die Formate unterscheiden sich strukturell und sind nicht austauschbar. Eine SSH-CA ist selbst lediglich ein SSH-Schlüsselpaar, keine X.509-CA.