SSH-Schlüssel im Proxmox-Cluster: Rotation, Vault und Zugriffskontrolle über alle Nodes

Ein typisches Bild beim ersten Audit eines mittelständischen Proxmox-Clusters: Zwei bis drei öffentliche Schlüssel in /root/.ssh/authorized_keys auf jeder Node, einer davon ohne Kommentar, einer gehört zum ehemaligen Dienstleister, der dritte ist ein alter Backup-Key, den niemand mehr zuordnen kann. Rotation seit Clusteraufbau: keine. Audit-Log, wer wann per SSH auf welcher Node war: Fehlanzeige. Technisch läuft der Cluster, organisatorisch ist er ein Compliance-Problem — spätestens dann, wenn eine Cyberversicherung oder ein ISO-Audit nach Zugriffskontrolle auf privilegierte Konten fragt.

SSH-Key-Management im Proxmox-Cluster ist deshalb kein Nice-to-have. Es ist der Unterschied zwischen “wir haben root-Zugriff” und “wir wissen genau, wer root-Zugriff hat, wann er ihn benutzt hat und wie wir ihn entziehen”. Dieser Artikel zeigt, wie wir bei Kunden ein sauberes Key-Management aufbauen — personalisierte Admin-Keys, Bastion-Host, optional HashiCorp Vault, Audit-Log und ein Rotationsprozess, der ohne Node-Reboot läuft.

Warum root@pve mit geteilten Keys der Normalfall ist — und warum das aufhören muss

Proxmox verteilt beim Clusteraufbau automatisch SSH-Keys zwischen den Nodes. Jede Node darf per SSH als root auf jede andere Node. Das ist technisch notwendig für Replikation, Migration und pvecm-Kommandos. Es führt aber dazu, dass die meisten Admins sich daran gewöhnen, einfach als root per SSH zu arbeiten — und ihre eigenen Public Keys ebenfalls direkt in /root/.ssh/authorized_keys zu legen.

In kleinen Umgebungen funktioniert das. In jedem Cluster, der länger als zwei Jahre läuft und mehr als einen Administrator sieht, wird daraus Chaos:

• Ex-Mitarbeiter-Keys bleiben jahrelang liegen, weil niemand den Überblick hat.
• Dienstleister-Keys werden nach Projektende nicht entfernt.
• Niemand kann im Nachhinein sagen, welcher Mensch um 03:47 Uhr qm destroy 101 ausgeführt hat — die Logs sagen nur “root”.
• Bei einer Fluktuation müssen theoretisch Keys von vier Nodes manuell entfernt werden — in der Praxis vergisst man eine.

Die saubere Antwort ist nicht “mehr Disziplin bei authorized_keys”, sondern: root@pve wird nur noch für den internen Cluster-Betrieb verwendet. Menschen bekommen personalisierte Konten, loggen sich darüber ein und werden einzeln auditiert.

Personalisierte Admin-Konten statt geteiltem root

Der erste Baustein ist das Trennen von System-Identität und Personen-Identität. Jeder Admin bekommt einen eigenen Linux-Account auf allen Nodes — zum Beispiel fschermer, mmueller, twebergmbh01 für einen externen Dienstleister. Diese Konten liegen in einer Admin-Gruppe, dürfen per sudo die relevanten Proxmox-Befehle ausführen, aber nicht direkt als root starten.

Die Konten werden idealerweise nicht lokal gepflegt, sondern zentral — über das zentrale Verzeichnis des Kunden (bei den meisten Mittelständlern Active Directory oder ein Open-Source-Pendant wie authentik oder Keycloak via SSSD/realmd) oder über ein kleines internes Verzeichnis speziell für die Infrastruktur. Entscheidend ist: Wenn ein Mitarbeiter geht, sperrt man ihn an genau einer Stelle und er ist überall gesperrt.

Für jeden Admin wird ein Ed25519-Schlüsselpaar erzeugt — niemals mehr RSA mit 2048 Bit, möglichst auch nicht mehr RSA mit 4096 Bit. Ed25519 ist schneller, kürzer und ausreichend sicher:

ssh-keygen -t ed25519 -C "florian.schermer@datazone.de-2026-11" -f ~/.ssh/id_dz_admin

Der Kommentar enthält Name und Monat des Rollouts. Das klingt banal, ist aber Gold wert, wenn man zwei Jahre später vor einer authorized_keys steht und entscheiden muss, welche Zeile raus kann.

Bastion-Host: Ein Eingangspunkt, nicht fünf

Der zweite Baustein ist ein Bastion- oder Jump-Host. In einem gesunden Setup sprechen Admins nicht direkt von ihrem Arbeitsplatz mit pve01, pve02 und pve03. Sie sprechen mit einer kleinen, gut gehärteten Bastion-VM — und von dort aus mit den Nodes.

Das klingt nach Umweg, bringt aber mehrere Vorteile auf einmal:

• Die Nodes sind in einem internen Management-Netz, das von außen nicht erreichbar ist.
• SSH-Port der Nodes wird komplett dichtgemacht, nur die Bastion darf.
• Das Audit-Log konzentriert sich an einer Stelle — die Bastion zeichnet jede Session auf.
• 2FA, Session-Recording und Rate-Limiting lassen sich einmal zentral konfigurieren statt dreimal pro Cluster.

Für den Bastion-Host reicht in den meisten Mittelständlern eine kleine Debian-VM mit gehärtetem OpenSSH. Wer schon mal den Grundstock gelegt hat, findet die wichtigsten Hardening-Schritte in unserem Artikel SSH Hardening: Sichere Fernwartung für Linux-Server — die Bastion wird genauso behandelt, nur strenger: keine ausgehenden Verbindungen außer SSH zu den Nodes, kein AllowTcpForwarding für Fremdziele, strikte AllowUsers-Liste.

Von außen geht der Admin per Ed25519-Key auf die Bastion, von dort über einen zweiten, auf der Bastion gespeicherten Key auf die Zielnode. Die Keys unterscheiden sich bewusst — einer wird am Arbeitsplatz gehalten, einer intern. Wird ein Admin-Laptop gestohlen, muss nur der Außen-Key gesperrt werden; die internen Keys bleiben unangetastet.

HashiCorp Vault als Option — nicht als Pflicht

In sehr vielen mittelständischen Setups reicht die Bastion-Lösung völlig aus. In Umgebungen mit höheren Compliance-Anforderungen (ISO 27001, NIS-2, Kundenverträge mit Finanz- oder Gesundheitssektor) lohnt sich eine Stufe mehr: dynamisch ausgestellte SSH-Zertifikate über HashiCorp Vault.

Das Grundprinzip ist einfach: Admin loggt sich bei Vault an — idealerweise über das zentrale Verzeichnis mit 2FA — und bekommt dafür ein kurzlebiges SSH-Zertifikat zurück, oft nur eine Stunde gültig. Die Nodes vertrauen nicht einzelnen Public Keys, sondern der CA von Vault. Vorteile:

• Zertifikate laufen von selbst ab — Rotation ist implizit.
• Es gibt keine authorized_keys mehr auf den Nodes zu pflegen.
• Vault führt Buch über jede Ausstellung — wer, wann, auf welche Rolle.
• Beim Ausscheiden eines Admins reicht ein Eintrag auf der Vault-Seite; keine Node wird angefasst.

Wir setzen Vault vor allem bei größeren Clustern (sechs Nodes aufwärts) oder bei Kunden mit mehreren Standorten ein. Für den klassischen 3-Node-Cluster beim Mittelständler ist Vault oft Overkill — hier gewinnt man mit sauberer Bastion, dokumentierten Keys und einem festen Rotationsrhythmus mehr Sicherheit pro investiertem Euro.

Audit-Log: Wer hat wann was gemacht

Zugriffskontrolle ohne Nachvollziehbarkeit ist halbe Arbeit. In unseren Setups laufen vier Logs parallel:

1. Bastion-Login-Log — jede eingehende SSH-Session mit User, Key-Fingerprint und Quell-IP, zentral per rsyslog/systemd-journal nach Loki oder in ein kleines Graylog.
2. Session-Recording auf der Bastion — mit Tools wie auditd plus ssh-session-log oder einfach script-Aufzeichnung. Für höhere Compliance eignet sich Teleport als Open-Source-Variante.
3. sudo-Log auf den Nodes — alle sudo-Aufrufe mit Zeit, User und Befehl.
4. Proxmox-Task-Log — Proxmox selbst protokolliert jede Aktion in /var/log/pve/tasks/. In Kombination mit dem sudo-Log lässt sich zweifelsfrei feststellen, welcher Mensch welche VM angelegt oder gelöscht hat.

Das zentrale Einsammeln dieser Logs ist wichtiger als die perfekte Visualisierung. Wir empfehlen, mindestens die Bastion- und sudo-Logs über Syslog an einen zentralen Collector zu schicken — idealerweise auf einem TrueNAS-Dataset mit Snapshot-Historie, damit Angreifer sie nicht einfach überschreiben. Wie wir TrueNAS für solche Log-Archive dimensionieren, zeigt der TrueNAS Konfigurator in der Variante “Backup/Log-Archiv”.

Rotationsprozess: Alle sechs Monate — ohne Node-Reboot

Keys werden nicht rotiert, wenn ein konkreter Vorfall das erzwingt. Sie werden rotiert, weil der Kalender es sagt. In unserem Standard rotieren wir alle sechs Monate — zusätzlich sofort, wenn ein Admin das Unternehmen verlässt oder ein Dienstleister wechselt.

Der Prozess läuft nach einem einfachen Schema ab:

1. Neuen Key erzeugen mit sprechendem Kommentar (florian.schermer@datazone.de-2026-11). Alter Key bleibt zunächst gültig.
2. Neuen Public Key an die Bastion verteilen — manuell oder, bei größeren Teams, per Ansible-Playbook. Die Bastion ist bewusst der einzige Ort, an dem personifizierte Keys liegen; die Nodes bekommen keine persönlichen Keys.
3. Login testen mit dem neuen Key, einmal pro Node.
4. Alten Key auf der Bastion entfernen nach erfolgreichem Test.
5. Alten Key auf dem Admin-Laptop sicher löschen (shred -u auf Linux, Secure-Delete auf macOS/Windows).
6. Rotation dokumentieren — Datum, Verantwortlicher, nächste geplante Rotation. Reicht in einer kleinen Markdown-Tabelle im internen Wiki.

Wichtig: Der Proxmox-interne SSH-Mesh zwischen den Nodes wird dabei nicht angerührt. Wir rotieren bewusst nur die menschlichen Admin-Keys, nicht die internen Cluster-Keys von Proxmox selbst — letztere werden beim Clusteraufbau einmal generiert und nur bei Fehlerbildern oder Node-Austausch neu erzeugt, nach Dokumentation von Proxmox mit pvecm updatecerts. Wer einen Node komplett austauscht oder neu einfügt, sollte den Prozess im Vorfeld mit uns oder einem anderen erfahrenen Dienstleister durchgehen — ein falscher Schritt kann die Clusterkommunikation blockieren. Mehr zum sauberen Clusterbetrieb steht in unserem Artikel zum Proxmox 3-Node-Cluster mit TrueNAS H20.

Zugriffsmatrix: Nicht jeder Admin braucht alles

Bei vielen Kunden merken wir in Workshops, dass die Diskussion über Keys die eigentliche Frage überdeckt: Wer soll überhaupt was dürfen? Ein Junior-Admin, der Backups prüft und VMs startet, braucht keinen Vollzugriff als root. Proxmox selbst bringt mit seinem rollenbasierten Zugriffsmodell einen zweiten Hebel neben SSH mit — und wir empfehlen, beides sauber zu kombinieren.

Konkret heißt das in der Praxis:

• Volle Admins: SSH über Bastion plus Proxmox-Rolle Administrator. Zwei bis vier Personen, nicht mehr.
• Operatoren: Nur Proxmox-Webinterface, Rolle PVEVMAdmin oder spezifische Pool-Rechte. Kein SSH.
• Monitoring/Backup-Rolle: Lesender Zugriff per API-Token mit begrenzten Rechten — kein SSH, kein Webinterface.
• Externe Dienstleister: Separate Konten, befristet, mit sprechendem Namen und zentral geloggt. Nach Projektende sofort entziehen.

Diese Trennung reduziert die Anzahl der Menschen, die überhaupt SSH-Zugriff brauchen, drastisch. Weniger Keys bedeuten weniger Rotation, weniger Audit-Aufwand und weniger Angriffsfläche. Für den Aufbau einer sauberen Rollentrennung sprechen wir im Rahmen unseres IT-Service regelmäßig mit Kunden — meistens als Teil eines größeren Infrastruktur-Checks.

Was wir im Alltag bei Kunden sehen — und was wir empfehlen

Aus den letzten Übernahmen bestehender Cluster lassen sich ein paar wiederkehrende Muster ableiten:

• Fast immer finden wir mindestens einen verwaisten Key. Rotation hat spürbaren Effekt.
• Fast nie finden wir ein zentrales Login-Log, mit dem man eine Session im Nachhinein nachstellen könnte. Die Bastion schließt diese Lücke mit überschaubarem Aufwand.
• Vault wird oft diskutiert, selten umgesetzt. Für die meisten Mittelständler ist der Return-on-Invest einer Bastion höher.
• Die größte Hürde ist nicht die Technik, sondern die Umgewöhnung der Admins — “einmal eben als root rein” ist eine schwer abzulegende Gewohnheit.

Unsere Empfehlung für ein typisches Setup (3–6 Nodes, 2–4 Admins, mittelständisches Umfeld):

1. Bastion-Host mit gehärtetem OpenSSH und Session-Logging.
2. Personalisierte Admin-Konten per sudo, keine direkten root-SSH-Logins durch Menschen.
3. Ed25519-Keys mit sprechenden Kommentaren.
4. Sechs-Monats-Rotation, dokumentiert im Wiki.
5. Audit-Logs zentral auf einem TrueNAS-Dataset mit Snapshots.
6. Vault optional, wenn Clustergröße oder Compliance es rechtfertigen.

Wenn Sie sich beim Lesen gefragt haben, wie das in Ihrem Cluster aussieht — ein Audit mit uns dauert typischerweise einen halben Tag und bringt eine klare Liste: Was ist in Ordnung, was muss raus, wo liegt die größte Lücke. Der TrueNAS Support deckt das für kombinierte Proxmox-TrueNAS-Umgebungen mit ab; für reine Proxmox-Betreuung läuft die gleiche Leistung über unseren allgemeinen IT-Service.

FAQ

Reicht nicht ein einziger Admin-Key, den alle kennen?

Technisch ja. Compliance- und auditmäßig nein. Sobald mehr als eine Person den Key kennt, ist nicht mehr nachvollziehbar, wer eine konkrete Aktion ausgelöst hat. Spätestens bei einem Sicherheitsvorfall oder einer Mitarbeiter-Trennung wird das zum Problem. Personalisierte Keys kosten in der Einrichtung einen Nachmittag und zahlen sich ab dem ersten Audit aus.

Was ist mit dem SSH-Mesh zwischen den Proxmox-Nodes selbst?

Das lässt man in Ruhe. Die internen Cluster-Keys von Proxmox werden beim Clusteraufbau einmal generiert und sind nötig, damit Live-Migration, Replikation und pvecm funktionieren. Wir rotieren bewusst nur die menschlichen Admin-Keys. Bei Node-Austausch oder nach einem bestätigten Sicherheitsvorfall wird der Mesh neu erzeugt — das ist aber kein Routinevorgang, sondern immer eine geplante Wartung.

Brauchen wir unbedingt HashiCorp Vault?

Nein. In einem typischen 3-Node-Cluster mit zwei bis vier Admins ist eine saubere Bastion-Lösung mit personalisierten Keys und dokumentierter Rotation völlig ausreichend und deutlich einfacher im Betrieb. Vault lohnt sich bei größeren Umgebungen, mehreren Standorten oder expliziten Compliance-Anforderungen, die kurzlebige Zertifikate verlangen.

Wie oft sollte man Admin-Keys rotieren?

Alle sechs Monate ist in der Praxis ein guter Mittelweg: oft genug, dass alte Keys nicht ewig durchrutschen, selten genug, dass es kein administrativer Dauerzustand wird. Zusätzlich sofort, wenn ein Admin das Unternehmen verlässt, ein Dienstleister wechselt oder ein Laptop verloren geht beziehungsweise gestohlen wird.

Wie trenne ich interne Admins von externen Dienstleistern wie DATAZONE?

Jeder externe Dienstleister bekommt ein eigenes, sprechendes Konto — bei uns typisch dz_<kundenkürzel> — und einen eigenen Key. Dadurch ist jederzeit klar, welche Aktion vom Dienstleister ausging und welche von intern. Beim Ende der Zusammenarbeit wird das Konto an genau einer Stelle gesperrt und der Dienstleister ist clusterweit raus. Das schafft Vertrauen in beide Richtungen — Kunde und Dienstleister wissen, dass sauber getrennt wird.

Was passiert, wenn der Bastion-Host ausfällt?

Dann kommt kurzzeitig niemand auf die Nodes — das ist bewusst so, verhindert aber keinen Betrieb der VMs. Für den Notfall empfehlen wir einen zweiten, baugleichen Bastion-Host, der im Normalbetrieb aus bleibt und bei Ausfall des primären Hosts per Konsole gestartet werden kann. Zusätzlich dokumentiert man einen “Break-Glass”-Zugang über die iLO/IPMI-Konsole der Nodes, der extrem restriktiv genutzt wird und dessen Zugangsdaten in einem physisch gesicherten Passwort-Tresor liegen.