Ein alter Administrator-Schlüssel liegt noch im Projektordner. Er funktioniert auf mehreren Servern, aber niemand weiß mehr genau, wer eine Kopie besitzt. Der Wechsel von Passwörtern zu SSH-Schlüsseln hat dann zwar die Anmeldung verändert, die Zuständigkeit jedoch nicht geklärt.
Eine brauchbare SSH-Verwaltung verbindet individuelle Identitäten, passende Zielrechte und einen verlässlichen Entzug. Je nach Umgebung reichen gepflegte öffentliche Schlüssel mit sauberem Inventar. Größere oder häufig wechselnde Umgebungen können von kurzlebigen SSH-Zertifikaten profitieren. Beide Wege benötigen einen betreubaren Betrieb.
Vier Dinge, die nicht verwechselt werden sollten
Der private Benutzerschlüssel ermöglicht den Nachweis der eigenen Identität. Er wird geschützt aufbewahrt und nicht per Chat, Mail oder ungeschütztem Projektordner verteilt. Der passende öffentliche Schlüssel kann auf den vorgesehenen Zielsystemen als zulässiger Zugang hinterlegt werden. Sein Fingerabdruck hilft bei der eindeutigen Zuordnung im Inventar.
Der Hostschlüssel identifiziert dagegen den angesprochenen Server. Die Hostprüfung verhindert, dass eine Verbindung unbemerkt beim falschen Gegenüber endet. Ein SSH-Zertifikat ergänzt einen öffentlichen Schlüssel um eine signierte Aussage, etwa zu Identität und Gültigkeit. OpenSSH-Zertifikate haben ein eigenes Format und sind keine gewöhnlichen TLS-/X.509-Zertifikate.
Persönliche Anmeldung und technische Jobs trennen
Für administrative Arbeit werden Personen und ihre berechtigten Aufgaben zugeordnet. Ein gemeinsam verteilter, langfristig gültiger Root-Schlüssel macht Austritt, Rotation und Nachvollziehbarkeit unnötig schwer. Individuelle Anmeldungen mit passend geregelten administrativen Rechten bieten dafür eine bessere Grundlage.
Ein Backup- oder Deployment-Job benötigt eine eigene technische Identität mit dokumentierter Zuständigkeit. Wo möglich wird sein Zugang auf die konkrete Funktion begrenzt, etwa durch einen vorgegebenen Befehl und passende Weiterleitungsregeln. Ein privater Mitarbeiterschlüssel soll nicht unbemerkt zur dauerhaften Voraussetzung eines automatischen Jobs werden.
Vom Schlüsselinventar zu kurzlebigen Zertifikaten
Bei wenigen Systemen kann eine kontrollierte Verteilung öffentlicher Schlüssel ausreichen. Das Inventar hält Person oder Dienst, Fingerabdruck, Zielsysteme, Umfang und den vorgesehenen Prüf- oder Wechseltermin fest. Entscheidend ist, dass die hinterlegten Berechtigungen auf allen betroffenen Zielen zuverlässig gepflegt werden.
Eine SSH-Zertifikatsstelle kann stattdessen öffentliche Schlüssel für einen begrenzten Zeitraum und definierte Identitäten signieren. Die Server vertrauen einer dafür vorgesehenen CA und prüfen ihre weiteren Regeln. Der private Anmeldeschlüssel muss dafür nicht an die CA verteilt werden. Die CA-Schlüssel und ihre Ausgaberegeln werden besonders geschützt.
Kurze Laufzeiten verringern die Nutzungsdauer eines ausgestellten Nachweises. Sie beenden aber keine bereits laufende Sitzung und ersetzen keinen Entzugsprozess. Auch die Ausstellung neuer Zertifikate muss nach einem Austritt unterbunden werden. Eine zentrale Secrets-Plattform ist eine mögliche Betriebsform; sie muss den konkreten SSH-Ablauf tatsächlich unterstützen.
| Verwaltungsweg | Wozu er passt | Was zum Betrieb gehört |
|---|---|---|
| Öffentliche Schlüssel pflegen | Überschaubarer, gut inventarisierter Zielbestand. | Verteilung, Entfernung alter Berechtigungen und Vertretung. |
| SSH-Zertifikate ausgeben | Begrenzte Gültigkeit und definierte Identitäten. | CA-Schutz, Ausgaberegeln, Serververtrauen und Entzug. |
| Technische Identitäten | Automatisierung mit klarer Aufgabe. | Begrenzte Zielrechte, Zuständigkeit und Wechselverfahren. |
| Agent oder Hardware-Schlüssel | Geeignete persönliche Anmeldewege. | Weiterleitungsgrenzen, Versionsprüfung und Wiederherstellung. |
Agent und Hardware-Schlüssel bewusst einsetzen
Ein SSH-Agent kann Anmeldungen mit geladenen Schlüsseln ermöglichen, ohne die private Schlüsseldatei auf jeden Zielserver zu kopieren. Eine Weiterleitung des Agenten gibt einem entfernten System allerdings Zugriff auf dessen Signaturmöglichkeiten. OpenSSH warnt ausdrücklich: Ein Angreifer mit ausreichendem Zugriff auf dieses System kann die geladenen Identitäten zur Anmeldung nutzen, auch ohne das Schlüsselmaterial auszulesen.
Agent-Weiterleitung wird deshalb nur für den benötigten Weg vorgesehen. Unterstützte zeitliche oder zielbezogene Einschränkungen können zusätzliche Grenzen setzen. Hardware-Sicherheitsschlüssel sind eine weitere Option für geeignete interaktive Zugänge. Client, Server, Schlüsseltyp und Berührungs- oder PIN-Anforderungen müssen zusammenpassen; ein unbeaufsichtigter Job hat andere Anforderungen als eine persönliche Anmeldung.
Rotation und Widerruf müssen am Ziel ankommen
Ein Austausch auf dem Notebook entfernt den alten Zugang noch nicht vom Server. Bei hinterlegten öffentlichen Schlüsseln müssen alle betroffenen Zielberechtigungen aktualisiert werden. Für Zertifikate können zusätzlich Sperrmechanismen wie OpenSSH Key Revocation Lists vorgesehen werden. Wirksam wird eine Sperre erst, wenn die vorgesehenen Server sie korrekt berücksichtigen.
Der Ablauf umfasst auch ein verlorenes Gerät, einen kompromittierten Schlüssel und einen ausgefallenen Verwaltungsdienst. Ein unabhängiger Notfallzugang wird geschützt, dokumentiert und kontrolliert getestet. Wiederherstellung darf nicht davon abhängen, dass genau der ausgefallene Zugangsweg noch funktioniert.
In Linux- und Proxmox-Umgebungen differenziert vorgehen
In heterogenen Umgebungen werden Versionen und tatsächlich unterstützte OpenSSH-Funktionen aufgenommen. Ein aktuelles Handbuch ist keine Garantie, dass jede vorhandene Linux-Installation dieselben Optionen besitzt. Neue Regeln werden mit einem vorgesehenen Testzugang und einem geprüften Rückweg eingeführt.
Proxmox VE verwendet SSH auch für eigene Clusterfunktionen, etwa bestimmte Konsolen-, Migrations- und Replikationswege. Diese technischen Vertrauensbeziehungen werden von persönlichen Administratorzugängen getrennt betrachtet. Eine pauschale Bereinigung oder Überschreibung von Schlüsseldateien kann den Betrieb stören. Änderungen werden deshalb gegen die Dokumentation der installierten Fassung geprüft.
Was ein überschaubarer Einstieg enthält
DAXS nimmt vorhandene SSH-Zugänge auf, ordnet Zuständigkeiten und plant einen passenden Verwaltungsweg. Im Pilot werden Anmeldung, Rechte, Entzug, Protokollierung und Wiederherstellung getestet. Eine erfolgreiche Anmeldung allein genügt als Abnahmekriterium nicht. Auch reine Anmeldelogs sind nicht automatisch eine vollständige Aufzeichnung sämtlicher ausgeführter Befehle.
Die Infrastrukturleistungen und der Beitrag zu Proxmox im Unternehmen ordnen den Betrieb ein. Für gemeinsam genutzte Portale ergänzt der Beitrag zu Tresoren, Rollen und Offboarding die Sicht. Sie können eine Bestandsaufnahme der administrativen Zugänge anfragen.
Häufige Fragen
Darf ich einen öffentlichen Schlüssel weitergeben?
Der öffentliche Teil ist für die passende Verteilung vorgesehen. Die Zuordnung zur richtigen Person und zum richtigen Ziel muss trotzdem geprüft werden. Der private Teil wird geschützt und nicht als gemeinsame Zugangsdatei herumgereicht.
Reicht ein kurz gültiges Zertifikat für sofortigen Entzug?
Nein. Ausgabe, verbleibende Gültigkeit, Sperrprüfung und bereits laufende Sitzungen müssen zusammen betrachtet werden. Ein kurzer Zeitraum ersetzt diesen Ablauf nicht.
Ist eine zentrale Zertifikatsstelle immer erforderlich?
Nein. Umfang, Wechselhäufigkeit, Automatisierung und Betriebsfähigkeit bestimmen die passende Lösung. Eine sauber gepflegte Schlüsselverwaltung kann für einen überschaubaren Bestand geeignet sein.
Quellen: OpenSSH: Anmeldung und autorisierte Schlüssel (externer Link) · OpenSSH: Zertifikate und Sperrlisten (externer Link) · OpenSSH: serverseitige Vertrauens- und Sperrregeln (externer Link) · OpenSSH: Agent-Weiterleitung (externer Link) · OpenSSH: Agent-Schlüssel und Einschränkungen (externer Link) · Proxmox VE: Administrationshandbuch, SSH im Cluster (externer Link)
Konzeptionelle Einordnung; konkrete Funktionen richten sich nach installierten Versionen und geplanter Verwaltung. Foto und Grafik zeigen keine echten Schlüssel, Kundenadressen oder interne Netzpläne.