Ceph cambia de cifrado: reiniciar la máquina virtual no refresca la clave

La frase más importante de la migración de claves de Ceph que Proxmox publicó el 9 de septiembre no está en el anuncio. Está enterrada en la documentación, en la lista de cómo refrescar los clientes, y son seis palabras: «A guest reboot is not enough». Reiniciar la máquina virtual no vale. Hay que migrarla en vivo o pararla y arrancarla. Y si no lo haces bien, no te enteras ese día: te enteras cuando caduque el ticket, que pueden ser minutos o pueden ser días.

Operamos Proxmox VE con almacenamiento Ceph en producción, así que esto nos toca a nosotros y a la mayoría de clústeres que mantenemos. El 9 de septiembre a las 02:39, en el foro oficial, Proxmox abrió el hilo «Cephx Key Migration Procedure and Ceph 19.2 Squid Going EOL Soon» y con él un procedimiento que no es opcional y que no se parece a un apt upgrade. Este artículo va de qué es exactamente, qué ha cambiado desde agosto, dónde está la trampa y en qué orden lo hacemos.

Tu clúster se puso en rojo él solo

El origen es de agosto. El 19 de agosto Ceph publicó a la vez 20.2.4 y 19.2.6 para cerrar cuatro CVE, y uno de ellos —CVE-2025-30156, un bypass de autenticación en cephx por mal uso de AES-CBC— no se arregla instalando el paquete. Hay que cambiar el tipo de las claves. Lo contamos entonces en el análisis de esos cuatro CVE, donde ya dijimos que había uno que el paquete no cierra por sí solo. Esto es la segunda mitad de aquello.

Lo describe Proxmox sin rodeos: «Recent security findings and fixes in Ceph make it necessary to upgrade ceph and migrate authentication keys from the aes to the aes256k cipher», y añade el matiz que decide la prioridad: «especially if your Ceph service networks are not isolated». Si tu red de servicio de Ceph está separada de verdad, respiras un poco. Si comparte switch con el resto, no.

Lo primero que nota la gente es que el clúster se pone en HEALTH_ERR sin haber tocado nada. No es un fallo. 19.2.6 y 20.2.4 traen comprobaciones de salud nuevas sobre el cifrado de las claves —la tabla de referencia de la documentación lista seis— y dos de ellas —AUTH_INSECURE_SERVICE_KEY_TYPE y AUTH_INSECURE_SERVICE_TICKETS— son de severidad error. La documentación lo aclara: «This does not mean that storage access or a Ceph service has failed». El almacenamiento sigue funcionando; lo que ha cambiado es lo que el semáforo mide.

Lo que ha cambiado desde agosto: ahora hay red

En agosto, rotar las claves cephx a mano era diez pasos y un clúster en rojo mientras durase. Eso es lo que Proxmox ha cambiado, y merece reconocerlo: han metido un script de migración —/usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys— y, sobre todo, han mejorado el mecanismo de claves en espera de Ceph para que el relevo sea gradual: «both keys remain valid while you refresh clients, including running guests and CephFS mounts, to use the new key».

Ese periodo de gracia es lo que de verdad aporta el procedimiento nuevo, y tiene requisitos concretos que conviene comprobar antes de empezar: pve-manager 9.2.17 o superior, y para la rotación escalonada de claves de cliente, Ceph 19.2.6-pve3, 20.2.4-pve3 o posterior en todos los monitores. La razón: un monitor antiguo promociona la clave pendiente en cuanto alguien la usa por primera vez, y con eso termina el periodo de gracia para todo el clúster. Por eso el script comprueba en cada ejecución que todos los monitores soportan la función, y se niega a dejar la clave nueva en espera si alguno no lo hace.

El reloj de esta avería no lo pones tú

El aviso de Proxmox: si retiras la clave vieja o restringes los cifrados antes de que todos los clientes estén refrescados, «incompatible or not-yet-refreshed clients may see I/O failures on reconnecting or when existing service tickets expire, which can be minutes or days after the change». Y: «Existing IO can appear to work until a reconnect and then fail».

Traducido a la vida real: ejecutas el comando a las 23:00 del sábado, miras el clúster, todo verde, todas las VM escribiendo, te vas a dormir. El martes a media mañana una máquina que nadie ha tocado pierde el disco. No es que el cambio fallara tarde; es que el cambio nunca falla en el momento en que se hace. La ventana de mantenimiento la fijas tú y la avería la fija el vencimiento de un ticket de servicio. Son dos relojes distintos, y el segundo no está en tu calendario.

De ahí la regla de la documentación: «Do not use --force to bypass a blocker». Un bloqueo puede ser una sesión que todavía lleva la clave antigua, pero también una verificación de versión que no cuadra o claves de demonios que ya no existen; en el propio hilo hay ejemplos de las tres cosas. Saltárselo no acelera la migración, mueve el fallo a un día en el que ya no estarás mirando.

Qué cuenta como «refrescar un cliente»

Antes de refrescar nada hay que saber qué tipo de cliente tiene cada carga, porque de eso depende si te sirve la biblioteca de espacio de usuario que ya has actualizado con el paquete o si dependes del kernel de la máquina. La documentación lo resume en tres líneas:

• Máquina virtual con discos RBD: espacio de usuario, salvo que tengas krbd activado.
• Contenedor sobre RBD: siempre cliente de kernel. Siempre. No hay variante.
• Montaje CephFS: kernel, salvo que uses fuse.

Para refrescar una VM afectada, la instrucción es migrarla en vivo desde el interfaz web, o pararla y arrancarla. Y detrás: «A guest reboot is not enough». Tiene toda la lógica cuando lo piensas —el proceso QEMU del host es el que sostiene la conexión con Ceph, y reiniciar el sistema operativo de dentro no lo toca—, pero es exactamente lo contrario de lo que hace el instinto de cualquiera al que le dicen «reinicia los clientes». Si alguien de tu equipo hace la ronda de reinicios desde dentro de las VM y te dice que ya está, no está.

Los contenedores y el resto de clientes RBD se paran y se arrancan. Los montajes CephFS los refresca el propio script si están ociosos, y deja en paz los que estén ocupados o no respondan: cuando nadie los use, se vuelve a ejecutar con --apply y se reintentan. Y hay un detalle que a nosotros nos parece el más fácil de olvidar en un clúster con trabajo nocturno: las copias, las restauraciones, las importaciones de disco y los clones sobre almacenamiento Ceph pueden conservar la clave con la que empezaron. Hay que dejarlos terminar antes de confirmar. Un backup largo que arrancó a las dos de la madrugada es un cliente con clave vieja aunque en la interfaz no lo parezca.

La puerta que decide si puedes terminar: kernel 7.0

Los programas de Ceph de los paquetes actualizados de Proxmox VE soportan aes256k. Los clientes de kernel, no todos: hace falta kernel 7.0 o superior en ejecución. Y esa frase, que en el hilo pasa como un requisito técnico más, es en realidad la que decide si tu clúster puede cerrar la migración este mes o no.

Conviene leer el requisito con cuidado, porque dice kernel en ejecución, no versión de Proxmox VE. Hagamos la cuenta con las versiones reales: Proxmox VE 9.2, publicado el 21 de mayo de 2026, trae el 7.0 como kernel predeterminado; Proxmox VE 9.1 iba con el 6.17 y 9.0 con el 6.14; y Proxmox VE 8 usa el 6.8 desde la 8.2, con el 6.14 disponible como opción desde la 8.4. Ahora bien, en toda la serie 9 el 7.0 está disponible como opt-in desde el 2 de abril —apt install proxmox-kernel-7.0 y reiniciar—, así que un nodo en 9.1 puede cumplir el requisito sin cambiar de versión mayor. La comprobación no es «¿en qué versión de Proxmox estoy?», es uname -r en cada nodo que aloje clientes de kernel, y hay que hacerla nodo por nodo: en un clúster que se ha ido actualizando por partes, conviven kernels distintos con toda naturalidad.

Para quien siga en Proxmox VE 8 la cadena se cierra sola y no es agradable: la rama 8 dejó de recibir soporte en agosto, no tiene kernel 7.0, y por tanto no puede completar el último paso de esta migración aunque instale todo lo demás. Lo correcto en ese caso es lo que dice la documentación: dejar la clave de ese usuario sin tocar y el cifrado antiguo habilitado, y silenciar el aviso mientras tanto. No restringir. Restringir con un cliente incompatible por ahí es exactamente el escenario del apartado anterior.

Lo que ya está pasando en el hilo

Seis días después del anuncio, el hilo sigue vivo y da para un retrato bastante honesto de cómo va esto. Hay quien lo ha hecho sin incidentes en un clúster de tres nodos y cuenta que la parte incómoda fue no saber cuándo seguir, porque muchos pasos no imprimen un verde claro de «esto ha ido bien». Hay quien pide que el procedimiento salga de la documentación general y tenga su propia guía, con el argumento de que es una migración de una sola vez y arriesgada, y no una tarea del día a día. Nos parecen dos quejas razonables.

Y hay, ya, gente con el clúster a medias. Dos usuarios han publicado el mismo mensaje después de ejecutar la rotación, Not a proper rbd authentication file:, cada uno sobre un fichero de claves distinto —CEPH00.keyring en un caso y ceph.keyring en el otro—, y uno de ellos con una máquina virtual que ya no arranca después de apagarla; explica que el origen fue un copiar-y-pegar que mezcló opciones de dos pasos distintos. Otros dos se han quedado bloqueados en la comprobación previa: a uno le falla porque uno de sus monitores vive en una máquina que Proxmox no gestiona y el script no puede verificarle la versión; al otro, porque el clúster aún reclama claves inseguras de dos gestores que ya no existen.

No lo contamos para señalar a nadie: lo contamos porque los tres casos dicen lo mismo. El riesgo de este cambio no está en la criptografía, que es la parte que ya está resuelta y probada. Está en el inventario: saber qué clientes tienes, cuáles no gestiona Proxmox, cuáles guardan una copia de la clave en un fichero suyo y cuáles llevan semanas sin reconectarse. Eso no lo sabe el script. Lo dice él mismo cuando lista las sesiones sospechosas: son pistas, no un inventario completo.

El orden que seguimos nosotros

No es un procedimiento alternativo al oficial —el oficial está bien y hay que seguirlo—, sino el orden en que lo encajamos nosotros para que la parte de inventario no quede para el final:

1. El inventario, antes que cualquier comando. Es el mismo primer punto que ya pusimos en agosto, y lo que el procedimiento nuevo le añade es que ahora el inventario decide también a quién puedes confirmar y a quién no. Qué usuarios de Ceph existen, qué carga usa cada uno, cuáles son clientes de kernel, qué hay fuera de Proxmox y dónde está copiada cada clave. Esto se hace en una hoja de cálculo y es la parte que decide si la migración sale bien.
2. Versiones y kernel. pve-manager 9.2.17 o superior, Ceph con sufijo -pve3 o posterior en todos los monitores, y kernel en ejecución 7.0 o superior en cada nodo que aloje clientes de kernel.
3. Primero las claves del clúster (--rotate-cluster-keys). Es el paso seguro: no toca las claves de almacenamiento ni client.admin, los tickets existentes siguen valiendo y el cifrado antiguo sigue habilitado. Con esto se limpian las dos comprobaciones de severidad error.
4. Paciencia con el aviso que queda. El de las claves rotativas de servicio puede tardar unas horas en desaparecer y se va solo. No bloquea la restricción final, así que no hay que esperarlo para seguir, pero conviene saberlo antes de empezar a dudar.
5. Preparar la clave nueva y refrescar, usuario a usuario. Migración en vivo o parar-arrancar; nunca reinicio del invitado. Dejar terminar copias y clones.
6. Comprobar con la herramienta correcta. pveceph auth status muestra los cifrados actuales y los pendientes; ceph auth ls no lista las claves pendientes, así que mirando ahí se ve un clúster más limpio de lo que está.
7. Confirmar solo al final, y solo si el inventario está cerrado. Si queda un cliente incompatible, se deja su clave y el cifrado antiguo, y se silencia el aviso. Un aviso silenciado con fecha de revisión es mejor gestión del riesgo que una restricción que tumba un contenedor el martes.
8. Y no borres el diario. /etc/pve/priv/cephx-key-migration.json guarda el progreso y contiene los secretos de las claves antiguas: se protege, y se conserva hasta que la migración esté completa. Si lo borras antes, pierdes lo que hace falta para reanudar.

Vale la pena saber que hay marcha atrás y que hay salida de emergencia, porque saberlo cambia cómo se aborda el paso arriesgado. Una clave nueva que está en espera se puede abortar con --abort-staged-key, que devuelve la clave actual a todas las copias gestionadas mientras las dos siguen valiendo. Pero no es un comando, son tres: abortar, refrescar a los clientes de vuelta —incluidos los desconectados y las copias externas— y confirmar con --confirm-abort-clients-refreshed; y si tus monitores no están en 19.2.6-pve4 o 20.2.4-pve4, que son los que saben identificar la clave de cada sesión, todos los clientes visibles de ese usuario tienen que desconectarse antes de confirmar. La marcha atrás cuesta casi tanto como la ida. Y si alguien se pasa de frenada y restringe los cifrados dejándose fuera la clave de administración, existe la opción de arranque mon_auth_emergency_allowed_ciphers, que sustituye la lista permitida en un monitor para recuperar el acceso. Sirve para recuperar el acceso y nada más: mientras esté puesto, Ceph levanta AUTH_EMERGENCY_CIPHERS_SET y el script se niega a hacer la restricción final.

Dos migraciones en el mismo trimestre

El calendario es lo que convierte esto en una decisión de dirección y no solo en una tarea de sistemas. Los paquetes llegaron hace poco a los repositorios sin suscripción, tras un periodo largo de pruebas internas, y Proxmox escribió el 9 de septiembre que planeaba sacarlos a los repositorios enterprise «in the second half of next week», avisando de que podía retrasarse unos días según el control de calidad y la respuesta del hilo. Esa semana que viene es esta. Si tus clústeres están en enterprise, la actualización que enciende las comprobaciones nuevas te puede llegar en cuestión de días, y con ella el HEALTH_ERR.

Y no viene sola. El mismo aviso recuerda que Ceph 19.2 Squid tiene fecha estimada de fin de vida el 31 de octubre de 2026, con la recomendación de subir a Tentacle mientras Squid siga soportado —y eso exige Proxmox VE 9.2 o superior, con lo que el que esté en la 8 tiene otra migración delante primero. De dónde sale esa fecha y por qué la tratamos como una estimación y no como una garantía lo contamos en el artículo sobre el commit que la movió.

Nuestra opinión, que es opinión y no dato, y que además no es nueva —la escribimos en agosto, con estas palabras: «no estrenar Tentacle a la vez»—: no las apiles. La rotación de claves y el salto de Squid a Tentacle son dos cambios que tocan lo mismo y fallan distinto, y juntarlos en la misma ventana ahorra una noche y complica el diagnóstico de la semana siguiente. Si algo se rompe el jueves, quieres poder decir qué cambió el sábado sin tener que elegir entre dos candidatos. Nosotros hacemos primero la rotación, la dejamos asentar unos días con el cifrado antiguo aún habilitado, y solo entonces tocamos versiones.

En este cambio, la comprobación de que ha salido bien no es que el clúster esté verde. Es que ningún cliente siga con la clave vieja. Son dos preguntas distintas, y solo la segunda la contesta el inventario que hiciste antes de empezar.

Nota de fuentes

El anuncio y las citas entrecomilladas sobre el procedimiento, el kernel 7.0, los clientes externos y el calendario del repositorio enterprise son del hilo «Cephx Key Migration Procedure and Ceph 19.2 Squid Going EOL Soon» del foro oficial de Proxmox, publicado por un miembro del equipo el 9 de septiembre de 2026 a las 02:39 (hora del foro). Los pasos, los nombres de las seis comprobaciones de salud, los requisitos de versión, la tabla de tipos de cliente, la frase «A guest reboot is not enough», el aviso sobre --force, el fichero cephx-key-migration.json, pveceph auth status, --abort-staged-key y mon_auth_emergency_allowed_ciphers están en la sección «Migrate Cephx Keys from aes to aes256k» de la documentación de referencia de Proxmox VE (pve-docs, capítulo pveceph). La atribución de CVE-2025-30156 al método antiguo es de esa misma sección; los cuatro CVE y las versiones 19.2.6 y 20.2.4 son del aviso combinado de Ceph del 19 de agosto de 2026. Las versiones de kernel por rama de Proxmox VE salen del wiki Proxmox VE Kernel; que el 7.0 sea el estándar en la 9.2, del anuncio oficial de Proxmox VE 9.2 del 21 de mayo de 2026; y que esté disponible como opt-in en la serie 9, del hilo «Opt-in Linux 7.0 Kernel for Proxmox VE 9 available» del 2 de abril de 2026, de donde sale también el comando de instalación. Los casos de usuarios y el mensaje de error citado son mensajes públicos del mismo hilo, consultados el 15 de septiembre de 2026; no los hemos reproducido con nombres. La fecha estimada de fin de vida de Squid (31 de octubre de 2026) es la que da el propio aviso de Proxmox. Lo que aquí es opinión nuestra —no apilar las dos migraciones, el orden de trabajo y que el riesgo está en el inventario— va dicho como tal en el texto.