ManagedPBS

Blog / Cephx-Upgrade in Ceph 19.2.6 unter Proxmox VE

Cephx-Upgrade in Ceph 19.2.6 unter Proxmox VE

11.09.2026

TL;DR

  • Ceph 19.2.6/20.2.4 fixt CVE-2025-30156 und führt dafür den neuen Cephx-Schlüsseltyp aes256k ein, der das unsichere alte aes-Verfahren ablöst.
  • Nach dem Update erscheinen ggf. zwei HEALTH_ERR-Warnungen – kein Ausfall, sondern nur der neue Check.
  • Voraussetzung: pve-manager ≥ 9.2.17, Ceph ≥ 19.2.6-pve3/20.2.4-pve3 auf allen Monitoren, Rolling Restart aller Dienste.
  • Migration läuft in 3 Schritten über /usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys: (1) Cluster-eigene Keys rotieren, (2) Keys kompatibler User staged rotieren + Clients refreshen, (3) final bestätigen und altes Cipher-Verfahren deaktivieren.
  • Vor Schritt 2 prüfen, ob alle Clients aes256k können (VMs, Container, CephFS-Mounts – Kernel-Clients brauchen Kernel ≥ 7.0).
  • client.admin zuletzt rotieren, Lockbox-Keys nie manuell ändern, --force vermeiden.

Mit den Ende August 2026 veröffentlichten Hotfix-Releases Ceph Squid 19.2.6 und Ceph Tentacle 20.2.4 hat das Ceph-Projekt vier CVEs geschlossen. Die wichtigste Änderung für Proxmox-VE-Betreiber betrifft dabei die Cephx-Authentifizierung: Als Reaktion auf CVE-2025-30156 führt Ceph erstmals einen neuen Schlüsseltyp namens aes256k ein und ersetzt damit das bisher verwendete, unsichere aes-Verfahren. Für PVE-Cluster mit hyperkonvergentem Ceph bedeutet das einen zusätzlichen, mehrstufigen Migrationsschritt nach dem eigentlichen Paket-Update.

Die konkreten Fehlermeldungen können so aussehen:

24 auth client entities with insecure key types
entity client.admin using insecure key type: aes
entity client.bootstrap-mds using insecure key type: aes
entity client.bootstrap-mgr using insecure key type: aes
entity client.bootstrap-osd using insecure key type: aes
entity client.bootstrap-rbd using insecure key type: aes
entity client.bootstrap-rbd-mirror using insecure key type: aes
entity client.bootstrap-rgw using insecure key type: aes
entity client.crash using insecure key type: aes
entity client.osd-lockbox.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX using insecure key type: aes
entity client.osd-lockbox.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX using insecure key type: aes
[...]
entity client.osd-lockbox.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX using insecure key type: aes

Monitors are configured to allow auth using insecure key types
insecure cipher aes allowed for auth

Monitors are configured to allow creation of insecure key types
no additional data

4 rotating auth service keys using insecure key types
rotating service keys for mon using insecure key type: aes
rotating service keys for mds using insecure key type: aes
rotating service keys for osd using insecure key type: aes
rotating service keys for mgr using insecure key type: aes

18 auth service entities with insecure key types
entity mds.pve01 using insecure key type: aes
entity mds.pve02 using insecure key type: aes
entity mds.pve03 using insecure key type: aes
entity osd.0 using insecure key type: aes
entity osd.1 using insecure key type: aes
entity osd.10 using insecure key type: aes
entity osd.11 using insecure key type: aes
entity osd.2 using insecure key type: aes
entity osd.3 using insecure key type: aes
entity osd.4 using insecure key type: aes
entity osd.5 using insecure key type: aes
entity osd.6 using insecure key type: aes
entity osd.7 using insecure key type: aes
entity osd.8 using insecure key type: aes
entity osd.9 using insecure key type: aes
entity mgr.pve01 using insecure key type: aes
entity mgr.pve02 using insecure key type: aes
entity mgr.pve03 using insecure key type: aes

Monitors are configured to issue insecure service tickets
no additional data

Warum plötzlich Health-Warnungen auftauchen

Direkt nach dem Upgrade auf 19.2.6 bzw. 20.2.4 können zwei neue Health-Checks mit dem Status HEALTH_ERR erscheinen, selbst wenn der Cluster vorher unauffällig lief:

  • AUTH_INSECURE_SERVICE_KEY_TYPE – ein Ceph-Dienstschlüssel nutzt noch das alte Verfahren
  • AUTH_INSECURE_SERVICE_TICKETS – Monitore stellen Service-Tickets noch mit dem alten Verfahren aus

Das ist kein Zeichen für einen tatsächlichen Ausfall von Storage-Zugriff oder Diensten, sondern lediglich die neue Prüfung, die auf das veraltete Schlüsselverfahren hinweist.

Voraussetzungen

Bevor die Migration gestartet werden kann:

  • pve-manager auf mindestens 9.2.17 aktualisieren und die aktuellen Ceph-Pakete auf allen Nodes installieren
  • Auf jedem Monitor mindestens Ceph 19.2.6-pve3 bzw. 20.2.4-pve3 vorliegen haben (Voraussetzung für die gestufte Client-Key-Rotation)
  • Rolling Restart aller Ceph-Dienste abschließen
  • Alle sonstigen Health-Warnungen/-Fehler beheben, die nicht Teil dieser Migration sind
  • Der Migrationshelfer darf nur als root auf einem Node gleichzeitig laufen

Der Migrationsablauf in drei Schritten

Proxmox stellt dafür das Skript pve-cephx-rotate-service-keys bereit, das jeweils zunächst im Dry-Run-Modus die geplanten Änderungen anzeigt.

1. Cluster-eigene Schlüssel rotieren

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

Rotiert automatisch die Schlüssel von Manager, MDS, OSD, Monitor, Bootstrap, Crash und den verschlüsselten OSD-Lockboxen. Storage-User-Keys und client.admin bleiben dabei unverändert. Nach kurzer Zeit verschwinden die beiden HEALTH_ERR-Meldungen.

2. Schlüssel kompatibler Ceph-User migrieren

Hier ist Vorsicht geboten: Ein Schlüssel darf nur rotiert werden, wenn alle zugehörigen Clients aes256k unterstützen. Faustregel:

VM mit RBD-Disk -> Wird unterstützt

Container auf RBD oder CephFS -> benötigt >= 7.0 Kernel

Danach wird gestaged:

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

Beide Schlüsselversionen bleiben zunächst gültig. Anschließend müssen betroffene VMs live-migriert oder neu gestartet werden (ein reiner Guest-Reboot reicht nicht), Container neu gestartet und laufende Backups/Restores/Clones abgewartet werden.

3. Migration abschließen

Ein letzter Dry-Run prüft auf verbliebene Sessions mit altem Schlüssel. Sind alle Clients aktualisiert, folgt:

/usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys --apply \
    --confirm-all-clients-refreshed --restrict-ciphers

Erst danach wird das alte, unsichere Cipher-Verfahren endgültig deaktiviert. Bleiben inkompatible Clients übrig, sollte deren Schlüssel unverändert bleiben und die entsprechende Warnung stattdessen per ceph health mute temporär stummgeschaltet werden – niemals mit --force erzwingen.

Wichtige Stolperfallen

  • Die Datei /etc/pve/priv/cephx-key-migration.json enthält den Fortschritt inklusive der alten Schlüssel im Klartext und sollte bis zum vollständigen Abschluss der Migration geschützt und aufbewahrt werden.
  • Lockbox-Schlüssel verschlüsselter OSDs niemals manuell per ceph auth rotieren – dafür ist ausschließlich der Migrationshelfer vorgesehen.
  • client.admin sollte zuletzt rotiert werden, idealerweise mit einem vorab getesteten Recovery-User als Absicherung.
  • Der aktuelle Status pro Schlüssel lässt sich über pveceph auth status einsehen – ceph auth ls zeigt gestagte Schlüssel nicht an.

Fazit

Das Cephx-Upgrade in 19.2.6/20.2.4 ist mehr als ein gewöhnliches Paket-Update: Es handelt sich um eine sicherheitsrelevante Migration der Authentifizierungsschlüssel, die Proxmox mit einem dedizierten, mehrstufigen und wiederholbaren Migrationswerkzeug abbildet. Wer die Reihenfolge (Cluster-Keys → kompatible User-Keys → finale Cipher-Restriktion) einhält und Clients konsequent vor der finalen Bestätigung aktualisiert, kann die Umstellung ohne Downtime durchführen.

← Alle Artikel