SSH-Schlüsselverwaltung: 7 bewährte Praktiken für 2026

Das Problem mit SSH-Schlüsseln

SSH-Schlüssel sind das Rückgrat des Serverzugriffs. Sie sind sicherer als Passwörter, einfach einzurichten und überall unterstützt. Doch wenn Ihr Team wächst, wächst auch die Komplexität ihrer Verwaltung.

Die meisten Teams beginnen mit einer Handvoll Schlüssel und kopieren öffentliche Schlüssel manuell auf die Server. Innerhalb eines Jahres verteilen sich Dutzende Schlüssel auf Laptops, CI/CD-Pipelines und gemeinsame Ordner. Niemand weiß, welche Schlüssel Zugriff auf welche Server geben. Wenn jemand geht, bedeutet die Zugriffsentziehung, sich auf jedem Server einzeln anzumelden.

7 bewährte Praktiken

1. Schlüsselverwaltung zentralisieren

Verwalten Sie keine Schlüssel mehr auf jedem Server. Nutzen Sie ein zentralisiertes System, das als alleinige Quelle der Wahrheit dafür dient, wer worauf zugreifen darf. Das macht Audits möglich und Widerruf sofort.

2. Schlüsselrotation einführen

SSH-Schlüssel sollten ein Ablaufdatum haben. Definieren Sie eine Rotationsrichtlinie - 90 Tage sind ein guter Ausgangspunkt. Automatisierte Rotation eliminiert das „Wir machen das später“-Syndrom, das in jahrelang gültigen Produktionsschlüsseln endet.

3. Zertifikatsbasierte Authentifizierung verwenden

SSH-Zertifikate sind im Team-Umfeld rohen Schlüsseln überlegen. Sie enthalten Metadaten (wer, was, wann, wo) und können zeitlich begrenzt werden. Ein Zertifikat, das in 8 Stunden abläuft, ist von Natur aus sicherer als ein Schlüssel, der ewig lebt.

4. Multi-Faktor-Authentifizierung erzwingen

SSH-Schlüssel allein sind eine Ein-Faktor-Authentifizierung. Kombinieren Sie sie mit TOTP, WebAuthn oder Hardware-Sicherheitsschlüsseln. Wenn ein Schlüssel kompromittiert wird, verhindert der zweite Faktor unbefugten Zugriff.

5. Jede Verbindung auditieren

Protokollieren Sie, wer sich wann von wo verbunden hat und was getan wurde. Ohne vollständige Audit-Logs können Sie weder Vorfälle untersuchen noch Compliance nachweisen oder die simple Frage beantworten: „Wer hat heute Nacht auf die Produktion zugegriffen?“

6. Prinzip der geringsten Rechte anwenden

Entwickler benötigen keinen Root-Zugriff auf alle Server. Definieren Sie rollenbasierte Zugriffsrichtlinien. Ein Frontend-Entwickler benötigt Zugriff auf den Staging-Server, nicht auf die Produktionsdatenbank.

7. Offboarding automatisieren

Wenn jemand geht, muss die Zugriffsentziehung automatisiert und sofort erfolgen. Manuelle Offboarding-Prozesse sind langsam, fehleranfällig und stellen ein Sicherheitsrisiko dar.

Wie SecurSSH hilft

SecurSSH setzt diese bewährten Praktiken nativ um: zentralisierte Verwaltung von SSH-Zugangsdaten in einem verschlüsselten Tresor, Audit-Log mit zwei Jahren Aufbewahrung, dreistufiges RBAC und sofortiger Widerruf durch Mitgliederentfernung. SSH-Zertifikatssignierung, TOTP-2FA für das Konto und verpflichtende Team-MFA stehen auf der Roadmap 2026. Einrichtung in 15 Minuten.