Proxmox VE 9.2 und Ceph 19.2.6 im Cluster aktualisieren: Erfahrungsbericht und Anleitung zur Cephx-Migration

Das Update auf Ceph 19.2.6 ist kein Routine-Update: Es schließt die Sicherheitslücke CVE-2025-30156 in der Cephx-Authentifizierung, wirkt aber erst vollständig, wenn alle Schlüssel auf den neuen Typ aes256k umgestellt sind. Wir haben unseren eigenen Proxmox-Cluster an einem Sonntag aktualisiert und migriert, ohne dass eine einzige VM ausgefallen ist. Hier beschreiben wir, wie wir vorgegangen sind und worauf Sie achten sollten.

Unser Setup ist ein typischer hyperkonvergenter Cluster: drei Knoten mit Proxmox VE und Ceph, 6 OSDs, je drei Monitore, Manager und Metadata-Server, dazu RBD-Speicher für VMs und CephFS für Container. Externe Clients außerhalb des Clusters greifen bei uns nicht auf Ceph zu. Das hat die Migration deutlich vereinfacht.

Die Sicherheitslücke CVE-2025-30156

Red Hat stuft die Lücke als „Important“ ein, mit einem CVSS-v3-Wert von 8,7. Veröffentlicht wurde sie am 1. Juli 2026.

Das Problem liegt im Design des Cephx-Protokolls. Der alte Schlüsseltyp aes verschlüsselt mit AES-128-CBC, einem fest eingebauten Initialisierungsvektor und ohne Integritätsschutz (HMAC). Das ist dieselbe Schwachstellenklasse, die einst Kerberos 4 unsicher gemacht hat.

So läuft ein Angriff ab:

Der Angreifer besitzt den Schlüssel eines einzigen, gering berechtigten Cephx-Clients.
Er fordert beim Ceph-Monitor Tickets für speziell benannte Identitäten an. Der Monitor verschlüsselt diese Namen und wird so zum „Verschlüsselungsorakel“.
Weil die Daten nicht gegen Veränderung geschützt sind, setzt der Angreifer die erhaltenen Blöcke zu gefälschten Zugangsdaten für privilegierte Dienste zusammen, etwa OSDs, MDS oder Manager.
Damit erhält er Zugriff auf den ganzen Cluster: Daten lesen, Daten zerstören und volle administrative Kontrolle.

Voraussetzung ist also ein bereits kompromittierter Client-Schlüssel und Netzwerkzugang zu einem Monitor. Wer sein Ceph-Netz strikt isoliert hat, ist weniger exponiert, aber nicht geschützt. Die eigentliche Abhilfe ist die neue Ceph-Version plus die Umstellung aller Schlüssel auf aes256k (AES-256-CTS-HMAC-SHA384-192). Quelle: Red Hat CVE-2025-30156

Versionen und Voraussetzungen

Die Korrektur steckt in Ceph Squid 19.2.6 und Ceph Tentacle 20.2.4. Proxmox liefert dazu ein Migrationsskript in pve-manager und eine Anleitung in pve-docs aus. Unser Cluster lief nach dem Update mit diesen Ständen:

Komponente	Version
Proxmox VE (pve-manager)	9.2.20
Kernel	7.0.14-19-pve
Ceph	19.2.6 Squid
QEMU (pve-qemu-kvm)	11.0.3

Zwei Punkte sind entscheidend:

Kernel 7.0 oder neuer. Die Kernel-Clients für RBD und CephFS beherrschen aes256k erst ab Kernel 7.0. Container und CephFS-Mounts nutzen diesen Kernel-Client, VMs mit krbd ebenfalls. Erst wenn auf allen Knoten ein 7.0-Kernel läuft, darf die Migration abgeschlossen werden.
Ceph Squid endet bald. Upstream läuft Squid voraussichtlich am 31.10.2026 aus. Proxmox empfiehlt, rechtzeitig auf Tentacle zu wechseln. Dafür braucht es Proxmox VE 9.2 oder neuer, wer noch auf Version 8 ist, muss zuerst dieses Upgrade erledigen.

Quellen: Ceph-Release-Notes 20.2.4/19.2.6, Proxmox-Anleitung zur Cephx-Migration, Upgrade Squid auf Tentacle

Vor dem Start

Diese Punkte sollten erledigt sein, bevor der erste Befehl läuft:

Aktuelle Backups aller wichtigen VMs und Container liegen vor.
Kein Backup läuft während des Wartungsfensters, prüfbar mit pgrep -a vzdump auf jedem Knoten.
Fremd-Repositories prüfen, etwa für Zabbix. Instabile oder unpassende Quellen vorher deaktivieren.
Externe Ceph-Clients erfassen: Backup-Server, eingebundene CephFS-Laufwerke, Skripte mit einer Kopie von ceph.client.admin.keyring. Das Migrationsskript sieht solche Clients nicht. Sie müssen von Hand den neuen Schlüssel bekommen, sonst sperren sie sich aus.
HA-Status prüfen mit ha-manager status, damit klar ist, welche Dienste beim Neustart eines Knotens umziehen.
Cluster gesund: ceph -s zeigt alle PGs active+clean.
Schlüssel sichern, als Rückweg für den Notfall:

mkdir -p /root/cephx-backup && chmod 700 /root/cephx-backup
ceph auth export > /root/cephx-backup/ceph-auth-export.txt
cp -a /etc/ceph /root/cephx-backup/etc-ceph
cp -a /etc/pve/priv/ceph /root/cephx-backup/pve-priv-ceph 2>/dev/null
chmod -R go-rwx /root/cephx-backup

Diese Sicherung enthält alle Zugangsschlüssel Ihres Ceph-Clusters. Behandeln Sie sie entsprechend und löschen Sie sie nach erfolgreichem Abschluss.

Schritt 1: Rollierendes Update der Knoten

Erst alle Knoten aktualisieren, dann nacheinander neu starten. So hat jeder Knoten, auf den HA die VMs verschiebt, bereits das neue QEMU installiert. Niemand muss überlegen, welche VM gerade mit welcher Version läuft.

Auf jedem Knoten nacheinander die Pakete einspielen, ohne Neustart:
```
apt update && apt full-upgrade
```
Vor dem Neustart eines Knotens verhindern, dass Ceph dessen OSDs als ausgefallen markiert und Daten umverteilt:
```
ceph osd set noout
```
Den Knoten neu starten. HA verschiebt die VMs live auf die anderen Knoten.
Warten, bis der Knoten zurück ist und ceph -s alle OSDs als up zeigt. Dann:
```
ceph osd unset noout
```
Erst wenn alle PGs wieder active+clean sind, den nächsten Knoten neu starten.

Zum Schluss bestätigen, dass überall dieselbe Version läuft:

ceph versions
pveversion -v | head -3

In ceph versions sollten Monitore, Manager, OSDs und MDS alle 19.2.6 melden. Das Webinterface zeigt den Fortschritt ebenfalls: Solange ein Knoten fehlt, stehen dessen OSDs unter „Outdated OSDs“.

Schritt 2: Keine Panik beim HEALTH_ERR

Nach dem Update meldet Ceph HEALTH_ERR. Das ist gewollt und bedeutet weder Datenverlust noch einen Ausfall. Die neue Version prüft die Schlüsseltypen und meldet jeden alten aes-Schlüssel als Sicherheitsproblem, etwa mit AUTH_INSECURE_SERVICE_KEY_TYPE, AUTH_INSECURE_CLIENT_KEY_TYPE oder AUTH_INSECURE_KEYS_ALLOWED.

Man kann die Meldungen mit ceph health mute vorübergehend stummschalten. Wir haben darauf verzichtet und die Migration direkt im Anschluss durchgeführt. Der Fehlerstatus verschwindet erst, wenn die Schlüssel umgestellt sind.

Welche Schlüssel betroffen sind, zeigt Proxmox übersichtlich an:

pveceph auth status

Die Ausgabe nennt die Schlüssel mit altem Typ, die erlaubten Cipher, die Kernel-Versionen aller Knoten und den nächsten empfohlenen Schritt. Im Webinterface führt der Link „Cephx migration guide“ im Ceph-Dashboard direkt zur Anleitung.

Schritt 3: Dienstschlüssel migrieren

Proxmox liefert für die Migration ein eigenes Skript. Ohne Optionen aufgerufen, ist es ein reiner Probelauf und ändert nichts:

/usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys

Der Probelauf zeigt, welche Schlüssel getauscht werden und was als Nächstes zu tun ist. Mit --apply führt das Skript den Plan aus. Bei uns lief dieser Schritt ohne einen einzigen Fehler:

Der Monitor-Schlüssel wurde getauscht. Die drei Monitore starteten dabei nacheinander neu und kehrten jeweils ins Quorum zurück.
Manager, MDS und alle 6 OSDs übernahmen den neuen Schlüssel im laufenden Betrieb. Nur die beiden Standby-Manager starteten kurz neu, die OSDs gar nicht.
Bootstrap- und crash-Schlüssel wurden ebenfalls getauscht, und die Service-Tickets werden ab jetzt mit aes256k ausgestellt.
Das Skript setzt noout selbst und hebt es danach wieder auf.

Danach steht der Cluster auf HEALTH_WARN statt HEALTH_ERR. Die Warnung AUTH_INSECURE_ROTATING_SERVICE_KEY_TYPE verschwindet in den folgenden Stunden von selbst, weil die Monitore ihre rotierenden Schlüssel nach und nach erneuern.

Wichtig: Das Skript legt /etc/pve/priv/cephx-key-migration.json an. Die Datei enthält die alten Schlüssel und ist der Rückweg, falls ein Dienst Probleme macht. Sie darf erst gelöscht werden, wenn die gesamte Migration abgeschlossen und der Zugriff überall geprüft ist.

Schritt 4: client.admin rotieren und den alten Cipher abschalten

Der letzte Schritt ist der heikelste, weil er alle Clients betrifft. Bei uns nutzen die Speicher für VMs (RBD) und Container (CephFS) keinen eigenen Ceph-Benutzer, sondern client.admin. Das ist bei Proxmox-Setups ohne eigene Benutzer üblich. Welche Speicher welchen Benutzer nutzen und ob krbd aktiv ist, zeigt:

grep -E '^(rbd|cephfs):' -A8 /etc/pve/storage.cfg | grep -E '^(rbd|cephfs):|krbd|username|monhost'

Der Ablauf:

Probelauf für Speicher- und Admin-Schlüssel:

/usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys --rotate-all-storage-keys --rotate-admin-key

Anwenden mit zusätzlich --apply. Der neue Schlüssel wird nur vorbereitet, alter und neuer gelten parallel. Noch kann nichts schiefgehen.
Alle Clients auffrischen. Am einfachsten schickt man jeden Knoten nacheinander kurz in den Wartungsmodus:
```
ha-manager crm-command node-maintenance enable <knoten>
```
Warten, bis alle Dienste den Knoten verlassen haben, dann mit disable zurückholen und warten, bis alle zurück sind. Dabei werden VMs live migriert, sie müssen nicht neu starten. Den Ceph-Schlüssel liest nämlich der QEMU-Prozess auf dem Host beim Start, nicht das Gastsystem. Container werden dagegen neu gestartet und haben eine kurze Unterbrechung.
Abschluss: Das Skript ohne Optionen aufrufen. Wenn alles bereit ist, gibt es den genauen Bestätigungsbefehl mit --confirm-all-clients-refreshed --restrict-ciphers aus. Erst dieser Befehl macht den alten Schlüssel ungültig und erlaubt nur noch aes256k.

Die Warnung von Proxmox gilt hier ausdrücklich: Den alten Schlüssel nie zurückziehen und die Cipher nie einschränken, bevor jeder Client kompatibel und aufgefrischt ist. Sonst drohen I/O-Fehler, und zwar nicht sofort, sondern beim nächsten Verbindungsaufbau oder wenn die bestehenden Tickets ablaufen. Das kann Minuten, aber auch Tage später passieren.

Abschlusskontrolle und Aufräumen

Ein, zwei Minuten nach dem Abschluss prüfen:

ceph -s | head -8
ceph health detail | grep -E '^\['
pveceph auth status | grep -A3 'Cipher settings'
ceph pg stat
ha-manager status | grep -vE 'started|^quorum|^master|^lrm|^fencing'

So sieht der gewünschte Endzustand aus:

ceph -s funktioniert. Das beweist, dass der Admin-Zugang mit dem neuen Schlüssel läuft.
Bei auth_allowed_ciphers steht nur noch aes256k.
Alle PGs sind active+clean, alle OSDs up und in.
Die letzte Befehlszeile gibt nichts aus, alle HA-Dienste laufen.
Höchstens die Warnung zu den rotierenden Dienstschlüsseln bleibt übrig. Sie verschwindet innerhalb weniger Stunden, danach steht der Cluster auf HEALTH_OK.

Nach etwa einer Woche ohne Auffälligkeiten können Sie aufräumen: die Datei /etc/pve/priv/cephx-key-migration.json und die eigene Schlüsselsicherung aus der Checkliste löschen. Beide enthalten Zugangsschlüssel und sollten nicht dauerhaft herumliegen.

Die Stolperfallen in dieser Version

Externe Clients werden übersehen. Das Skript erfasst nur, was Proxmox verwaltet. Ein Backup-Server mit eingebundenem CephFS oder ein Skript mit kopiertem Keyring sperrt sich nach dem letzten Schritt aus. Solche Systeme müssen Sie selbst finden und mit dem neuen Schlüssel versorgen.
Ein alter Kernel läuft noch. Ein installierter 7.0-Kernel reicht nicht, er muss auch laufen. pveceph auth status zeigt die laufenden Kernel-Versionen aller Knoten an.
Ein Gast-Neustart reicht nicht. Für VMs zählt der QEMU-Prozess auf dem Host. Nur eine Live-Migration oder ein Stopp mit anschließendem Start lädt den neuen Schlüssel, ein Neustart aus dem Gast heraus nicht.
Fehler kommen verzögert. Wer zu früh den alten Cipher abschaltet, merkt das oft nicht sofort. Bestehende Tickets laufen weiter, bis sie ablaufen.
Backups während der Migration. Laufende vzdump-Jobs vorher abwarten, sonst kollidieren sie mit Migrationen und Neustarts.
Squid läuft aus. Wer jetzt auf 19.2.6 geht, muss das Upgrade auf Tentacle trotzdem bald einplanen.

Fazit

CVE-2025-30156 ist eine ernste Lücke, aber gut beherrschbar. Das Migrationsskript von Proxmox nimmt einem den größten Teil der Arbeit ab, und durch die parallele Gültigkeit von altem und neuem Schlüssel gibt es bis zum letzten Befehl einen Rückweg. Bei uns liefen Update und Migration rollierend durch, ohne dass eine VM ausgefallen ist.

Der wichtigste Rat: Schritt für Schritt vorgehen, nach jedem Schritt den Zustand prüfen und den letzten Befehl erst dann absetzen, wenn wirklich jeder Client aufgefrischt ist. Und weil Ceph Squid am 31.10.2026 ausläuft, steht für die meisten Proxmox-Cluster bald schon das nächste Wartungsfenster an: das Upgrade auf Tentacle