После обновления Ceph появились предупреждения AUTH_INSECURE_*, хотя виртуальные машины продолжают работать? В Squid 19.2.6 и Tentacle 20.2.4 появились проверки старого типа ключей cephx — aes. Для устранения проблемы нужно обновить совместимые службы и клиенты, заменить ключи на aes256k, переподключить пользователей хранилища и только затем запретить старый шифр.

Переход с Squid на Tentacle и миграция ключей — две отдельные операции. Простое обновление пакетов не гарантирует, что старые ключи заменены. А преждевременный запрет aes способен лишить ВМ и контейнеры доступа к дискам при следующем подключении, даже если сразу после изменения всё выглядит исправным.

Ниже разобран локальный Ceph, установленный средствами Proxmox VE, с хранилищами RBD и CephFS. Требования к версиям приведены по состоянию на 8 октября 2026 года. Для Ceph под управлением cephadm или Rook, внешних MON и дополнительных шлюзов нужен план с учётом их собственного управления службами и ключами.

Что означают предупреждения Ceph insecure keys

Cephx проверяет подлинность служб и клиентов Ceph с помощью секретных ключей. Старый механизм aes затронут уязвимостью CVE-2025-30156. Новые проверки показывают, какие части кластера ещё используют его или разрешают такое использование.

Сначала получите полный текст сообщений:

ceph -s
ceph health detail

Первые две проверки могут перевести Ceph в HEALTH_ERR при работающем хранилище. Поэтому смотрите причину статуса: предупреждение о ключах само по себе не доказывает повреждение данных. Ошибки OSD, потеря кворума и недоступные группы данных требуют отдельного устранения.

Сообщения AUTH_INSECURE_GLOBAL_ID_RECLAIM и AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED относятся к другой проверке безопасности. Старые инструкции про auth_allow_insecure_global_id_reclaim не заменяют миграцию ключей на aes256k.

Нужно ли сначала переходить на Tentacle

Миграция cephx поддерживается и в исправленном Squid. Выберите порядок по своей задаче:

• Уже установлен Tentacle: проверьте пакеты, запущенные службы и клиентов, затем переходите к разделу о миграции ключей.
• Нужно устранить предупреждения, оставаясь на Squid: используйте актуальные исправленные сборки Squid и выполните ротацию на этой ветке.
• Запланированы обе операции: удобно сначала завершить обновление до Tentacle, проверить службы и затем отдельно выполнить миграцию cephx. Не запускайте ротацию ключей одновременно с обновлением или последовательным перезапуском служб.

По опубликованному графику Ceph ожидаемое завершение поддержки Squid — 31 октября 2026 года. Поэтому замену ключей на Squid стоит рассматривать отдельно от дальнейшего перехода на поддерживаемую ветку. Если ключи уже успешно переведены на aes256k, после обновления до Tentacle повторная ротация только из-за смены версии не требуется.

Что проверить и сохранить до начала работ

Версии пакетов и работающих служб

Для описанной процедуры используйте Proxmox VE 9.2 с pve-manager версии 9.2.19 или новее. На каждом узле выполните:

pveversion -v
uname -r
ceph --version
apt policy pve-manager ceph-common librados2 librbd1

Команда ceph --version показывает версию локальной программы. Чтобы увидеть версии реально работающих демонов во всём кластере, выполните:

ceph versions

Для перехода Squid → Tentacle исходный Squid должен быть не ниже 19.2.3-pve3. Перед миграцией cephx нужны актуальные пакеты исправленной ветки: Squid 19.2.6 или Tentacle 20.2.4 и соответствующие обновления Proxmox.

Подготовка клиентского ключа с одновременной действительностью старого и нового требует как минимум 19.2.6-pve3 или 20.2.4-pve3 на каждом MON. Предпочтительны актуальные сборки pve4 или новее: они позволяют определить, каким ключом пользуется подключённый клиент, и не требуют отключать уже обновлённые подключения при подтверждении.

Проверяйте также вычислительные узлы без OSD, MON и MGR. Они используют Ceph-библиотеки для доступа к дискам ВМ. Обновление только серверов хранения оставляет старые клиенты в эксплуатации. После установки пакетов нужно завершить последовательный перезапуск соответствующих служб: новые файлы на диске ещё не означают, что работающие процессы их используют.

Состояние данных, кворум и доступ к узлам

ceph -s
ceph health detail
ceph osd tree
ceph osd df
ceph quorum_status --format json-pretty
pvecm status

До работ должны быть доступны штатные MON и кворум Proxmox, OSD должны находиться в состоянии up/in, а группы размещения данных — PG — в нормальном состоянии active+clean. Не начинайте плановую миграцию при недоступных PG, проблемах дисков, переполнении, незавершённом восстановлении или необъяснённых предупреждениях.

Описанные выше проверки cephx разбираются отдельно: их появление после исправлений безопасности не равнозначно отказу хранения. Все остальные ошибки сначала устраните. Убедитесь, что с узла, где будет запущен помощник, доступен SSH ко всем участвующим узлам.

Резервные копии и возможность обслуживания одного узла

Сделайте актуальные резервные копии ВМ, контейнеров и важных данных CephFS вне обновляемого Ceph. Проверьте восстановление хотя бы одной репрезентативной ВМ. Снимок диска в том же кластере не решает задачу восстановления при потере доступа ко всему хранилищу.

Отдельно сохраните конфигурацию Ceph, /etc/pve/storage.cfg, настройки репозиториев и ключи. Экспорт базы аутентификации можно записать в новый закрытый каталог:

umask 077
CEPH_BACKUP_DIR="/root/ceph-before-migration-$(date +%Y%m%d-%H%M%S)"
mkdir "$CEPH_BACKUP_DIR"
ceph auth export > "$CEPH_BACKUP_DIR/auth.keyring"
ceph config dump > "$CEPH_BACKUP_DIR/config.txt"

Экспорт аутентификации не охватывает все локальные копии ключей. Сохраните также используемые файлы в /etc/pve/priv/ceph/, административный /etc/pve/priv/ceph.client.admin.keyring, общий /etc/pve/priv/ceph.mon.keyring и локальные keyring служб на соответствующих узлах. Защищённую копию вынесите за пределы кластера. Эти файлы содержат секреты; прикладывать их к публичному сообщению на форуме нельзя.

Заранее проверьте удалённую консоль и запас ресурсов для переноса нагрузки. Последовательное обслуживание требует, чтобы оставшиеся узлы выдерживали нагрузку и сохраняли доступность данных. Не уменьшайте число реплик или min_size ради прохождения обновления.

Если под кластер требуется подобрать арендуемое оборудование, рассмотрите выделенные серверы HSTQ. В запросе укажите число узлов, диски под OSD, требования к приватной сети и удалённой консоли. Доступность VLAN, дополнительных портов и IPMI/KVM нужно согласовать для выбранной площадки. Администрирование Ceph и перенос данных оформляются отдельно от базовой поддержки оборудования и сети.

Как обновить Ceph с Squid до Tentacle

Этот раздел выполняется только для смены ветки. Команды ceph изменяют состояние всего кластера и обычно запускаются один раз с административного узла. Операции с APT и systemd выполняются на конкретных узлах.

1. Измените репозиторий Ceph на всех узлах

Найдите действующую запись Ceph в /etc/apt/sources.list.d/ceph.sources либо в старом ceph.list. Сохраните её копию. Замените ветку ceph-squid на ceph-tentacle, сохранив выбранный канал и корректные параметры подписи.

Для enterprise-репозитория с действующей подпиской запись формата deb822 выглядит так:

Types: deb
URIs: https://enterprise.proxmox.com/debian/ceph-tentacle
Suites: trixie
Components: enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Для канала no-subscription:

Types: deb
URIs: http://download.proxmox.com/debian/ceph-tentacle
Suites: trixie
Components: no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Используйте один подходящий вариант. Не оставляйте одновременно активные записи Squid и Tentacle, в том числе в разных файлах. Для Proxmox VE 9 значение Debian suite остаётся trixie: имя релиза Ceph не подставляется вместо него. Добавлять тестовый репозиторий для обычного перехода не требуется.

2. Установите пакеты на всех узлах

Перед плановыми перезапусками можно включить noout, предварительно записав исходное состояние флагов:

ceph osd dump
ceph osd set noout

Этот флаг предотвращает автоматический вывод временно недоступных OSD из состава кластера. Он не обеспечивает резервирование и не делает безопасной одновременную остановку нескольких серверов.

На каждом узле, включая узлы, работающие только как клиенты Ceph:

apt update
apt full-upgrade

Просмотрите предлагаемые изменения до подтверждения. Ошибки репозитория, несовместимые зависимости или неожиданное удаление основных пакетов Proxmox/Ceph нужно устранить до продолжения. Не добавляйте -y, чтобы пропустить эту проверку.

Сначала завершите установку пакетов на всех участвующих узлах. Затем переходите к перезапускам в порядке ниже.

3. Перезапустите MON, затем MGR

MON — мониторы, поддерживающие карты кластера и кворум. На одном узле с MON выполните:

systemctl restart ceph-mon.target

Проверьте ceph -s и ceph quorum_status --format json-pretty. Только после возвращения монитора в штатный кворум переходите к следующему. Не перезапускайте все MON одновременно.

После обновления всех MON проверьте:

ceph mon dump

В выводе ожидается min_mon_release 20 (tentacle). Если MON не вернулся в кворум, остановите дальнейшие перезапуски и разберите состояние этого узла.

Далее последовательно перезапустите MGR — службы управления и сбора состояния — на узлах, где они установлены:

systemctl restart ceph-mgr.target

Проверяйте наличие активного MGR и предусмотренных резервных экземпляров через ceph -s.

4. Обновите работающие OSD по одному серверу

OSD обслуживают данные на накопителях. Сначала определите по ceph osd tree все OSD выбранного узла и проверьте возможность их совместной остановки.

Например, если на узле находятся только OSD 0 и 1:

ceph osd ok-to-stop 0 1

Числа в примере замените полным списком OSD своего узла. Успешная проверка означает, что их остановка в текущем состоянии не должна немедленно лишить данные доступности. Отказ или невозможность сделать вывод — причина остановиться, а не обходить проверку.

После успешной проверки на выбранном узле:

systemctl restart ceph-osd.target

Дождитесь возвращения всех его OSD в up/in и восстановления нормального состояния PG. Только затем обслуживайте следующий сервер. Если после перезапуска остаются down, ошибки доступа или восстановление данных, переход на следующий узел откладывается.

5. Если используется CephFS, отдельно обновите MDS

MDS обслуживают метаданные файловой системы CephFS. Если CephFS отсутствует, этот этап пропускается.

Для каждой файловой системы получите её имя и текущие параметры:

ceph fs ls
ceph fs status
ceph fs get FS_NAME

Здесь и ниже FS_NAME заменяется настоящим именем файловой системы. Запишите исходные значения max_mds и allow_standby_replay.

1. Отключите standby-replay: ceph fs set FS_NAME allow_standby_replay false.
2. Оставьте один активный ранг: ceph fs set FS_NAME max_mds 1.
3. Дождитесь, пока активным останется только rank 0. Проверьте роли через ceph fs status.
4. Остановите резервные MDS. Для отдельного экземпляра на его узле используется systemctl stop ceph-mds@MDS_ID.service, где MDS_ID — проверенное имя демона.
5. Перезапустите оставшийся активный MDS командой systemctl restart ceph-mds@MDS_ID.service и дождитесь его нормального активного состояния.
6. Запустите остановленные резервные экземпляры: systemctl start ceph-mds@MDS_ID.service.
7. Верните прежние значения max_mds и allow_standby_replay, затем проверьте активные и резервные MDS.

Проверяйте роль каждого экземпляра перед остановкой. Если на сервере несколько MDS, общий ceph-mds.target затронет их все. На время переключения активного MDS возможна пауза файловых операций; гарантировать отсутствие задержек для приложений нельзя.

6. Завершите переход ветки

Проверьте ceph versions. Когда все OSD действительно работают на Tentacle, выполните:

ceph osd require-osd-release tentacle

Команда закрепляет минимальную допустимую версию OSD. После перехода не рассчитывайте на возврат к Squid простой установкой старых пакетов: план восстановления должен опираться на проверенные резервные копии и совместимое окружение.

Когда все OSD вернулись и обслуживание закончено, снимите noout, если установили его именно для этой процедуры:

ceph osd unset noout
ceph -s
ceph versions

Новые сообщения cephx после обновления разбираются следующим этапом. Не запускайте помощник миграции, пока ещё продолжаются перезапуски служб.

Какие клиенты нужно подготовить к aes256k

Перед заменой клиентских ключей составьте список всех потребителей каждого Ceph-пользователя. Один ключ может использоваться несколькими хранилищами, административными командами и внешними серверами. Особенно внимательно проверьте client.admin.

Для клиентов ядра Proxmox документация требует запущенное ядро 7.0 или новее. Проверка — uname -r. Установленный пакет нового ядра не помогает, пока узел продолжает работать на старом. Перезагрузки узлов планируйте по одному, с сохранением кворума и доступности данных.

У сторонних дистрибутивов возможны обратные переносы исправлений в более старые ядра. Совместимость подтверждается документацией поставщика или проверкой конкретной сборки. Номер версии установленного Ceph сам по себе не подтверждает возможности клиента ядра.

Ядро гостевой ОС не определяет совместимость обычного виртуального RBD-диска: к Ceph обращается узел Proxmox. Если же сама ВМ монтирует CephFS или подключает RBD напрямую, она становится отдельным клиентом и проверяется самостоятельно.

Настройки krbd, fuse, имя пользователя и monhost проверяйте в соответствующем разделе /etc/pve/storage.cfg. Если хотя бы один потребитель ключа несовместим или неизвестен, этот ключ пока не ротируйте. Обновите клиента, перенесите нагрузку на совместимый способ доступа либо отложите клиентский этап. Один переход сервера хранения на Tentacle совместимость старого клиента не исправляет.

Как выполнить миграцию cephx в Proxmox

Используйте штатный помощник:

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

Запускайте его от root на одном узле. По умолчанию он проверяет состояние и показывает план без ротации ключей. После каждого этапа снова запускайте его без параметров: он определяет оставшиеся действия и умеет продолжать прерванную работу.

Не запускайте второй экземпляр миграции с другого узла и не меняйте параллельно ключи командами ceph auth. Отсутствие файла помощника или ошибки распознавания параметров — повод проверить версию pve-manager.

Этап 1. Замените ключи, принадлежащие кластеру

Сначала просмотрите план:

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

Если проверка не обнаружила препятствий, примените ту же операцию:

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

Помощник обрабатывает ключи MON, MGR, MDS, OSD и служебных пользователей, включая lockbox зашифрованных OSD. При необходимости он перезапускает службы по очереди. Ключи пользователей хранилищ и client.admin на этом этапе сохраняются.

После пересчёта состояния должны исчезнуть две проверки уровня ошибки: AUTH_INSECURE_SERVICE_KEY_TYPE и AUTH_INSECURE_SERVICE_TICKETS. Сообщение о rotating service keys может оставаться несколько часов. Само по себе оно не требует повторной ротации и не мешает продолжению процедуры.

Lockbox-ключ позволяет зашифрованному OSD получить ключ разблокировки накопителя. Его копии должны совпадать в Ceph и метаданных устройства. Поэтому его нельзя заменять только через ceph auth, обходя помощник. Миграция cephx не означает повторное шифрование всех пользовательских данных.

Этап 2. Подготовьте новые ключи совместимых клиентов

Следующая команда охватывает пользователей управляемых локальных RBD/CephFS-хранилищ и client.admin. Используйте её только после проверки всех потребителей этих учётных записей:

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

При отсутствии препятствий:

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

Новый ключ становится подготовленным — staged, или pending. До подтверждения старый и новый ключи остаются действительными. Помощник записывает новые значения в управляемые файлы, а клиенты должны перечитать их.

Пока есть подготовленные ключи, не добавляйте и не понижайте версии MON, не изменяйте те же учётные записи сторонними средствами. Предупреждение AUTH_INSECURE_CLIENT_KEY_TYPE до окончательного подтверждения ещё допустимо.

Этап 3. Переподключите всех пользователей ключей

• ВМ: выполните live migration через интерфейс Proxmox либо штатно выключите и заново запустите ВМ. Обычной перезагрузки внутри гостевой ОС недостаточно: процесс QEMU может сохранить старый ключ.
• Контейнеры на RBD: остановите и запустите их, чтобы обновить подключение хранилища.
• CephFS: помощник обновляет свободные монтирования. Занятые нужно освободить и повторить запуск с --apply. Проверьте в том числе подключённые к ВМ ISO-образы с CephFS: они могут удерживать файловую систему.
• Бэкапы, восстановления, импорты и клонирование: дождитесь завершения операций. Они могут продолжать пользоваться ключом, с которым начались.
• Внешние клиенты: безопасно передайте подготовленный ключ нужного пользователя, обновите все его копии и выполните предусмотренный клиентом перезапуск или перемонтирование.

Подготовленные учётные данные локального кластера находятся в управляемых файлах:

• RBD: /etc/pve/priv/ceph/<STORAGE_ID>.keyring;
• CephFS: /etc/pve/priv/ceph/<STORAGE_ID>.secret;
• административный пользователь: /etc/pve/priv/ceph.client.admin.keyring.

Используйте файл именно того пользователя, которому принадлежит подключение. Файл .secret содержит секрет, а keyring — оформленную запись пользователя: это разные форматы.

Особый случай — monhost. Proxmox считает такое хранилище внешним, даже если перечисленные MON фактически относятся к локальному кластеру. Помощник не обновляет его копию ключа автоматически. Если пользователь этого хранилища ротируется, соответствующую копию нужно обновить отдельно до подтверждения.

Ключи действительно внешнего Ceph-кластера этот помощник не меняет. Их ротацию выполняют по процедуре владельца внешнего кластера.

Этап 4. Подтвердите переход и ограничьте шифры

/usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys
pveceph auth status

Проверьте оставшиеся старые сессии, подготовленные ключи и указанные помощником препятствия. Его список подключений не заменяет ваш перечень клиентов: выключенный сервер резервного копирования или сохранённая на NAS старая копия ключа могут быть ему не видны.

Только когда все потребители обновлены, выполняйте точную следующую команду, которую напечатал актуальный помощник. В финальном плане могут использоваться --confirm-all-clients-refreshed и --restrict-ciphers вместе с --apply.

Первое подтверждение делает новые клиентские ключи текущими и лишает старые действительности. Ограничение шифров запрещает оставшиеся подключения через aes. Эти действия нельзя использовать как способ просто убрать предупреждение.

Продолжающийся ввод-вывод не доказывает завершение миграции. Клиент способен потерять доступ только при обновлении сеанса, переподключении или следующем запуске. Поэтому все ключи и подключения проверяют до финального запрета.

Что делать, если миграция остановилась или предупреждения остались

Помощник прервался, узел был недоступен или служба не запустилась

Восстановите доступность узла, проверьте конкретную службу и её журнал. Затем запустите помощник без параметров и следуйте оставшемуся плану. Если ошибка сохраняется, проверьте наличие более новой версии pve-manager.

Не удаляйте /etc/pve/priv/cephx-key-migration.json, чтобы «начать заново». Журнал содержит состояние операции и секретные ключи, необходимые для восстановления отставших служб. Сохраняйте его до завершения миграции и проверки доступа; не публикуйте содержимое.

Не заменяйте целиком /etc/pve/priv/ceph.mon.keyring случайной копией: файл может содержать несколько нужных записей. Ручное восстановление должно учитывать общие и локальные копии ключей.

Ошибка «not every monitor answered the session query»

Помощник не получил полный список сессий от MON и поэтому не может подтвердить безопасность отключения старых ключей. Проверьте кворум, доступность узлов по SSH, одинаково актуальные пакеты MON и завершение их перезапусков. Запуск с --verbose помогает получить подробности проверки.

В обсуждениях пользователям иногда помогали исправление SSH-доступа или запуск с другого исправного узла, но смена узла помогала не всем. Не обходите проверку и не ограничивайте шифры вручную. После исправления выявленной причины повторите обычную проверку помощником.

Ошибка «Not a proper rbd authentication file»

После появления нового типа ключа сначала проверьте клиентские пакеты на узле, который открывает RBD. В обсуждениях Proxmox этот симптом встречался при отставших клиентских пакетах, в том числе на узлах без служб хранения.

Обновите Ceph-библиотеки из правильного репозитория, затем повторите проверку подключения. Если ошибка осталась, проверьте пользователя, путь и формат файла ключа. Не регенерируйте client.admin наугад: проблема может быть в клиенте, который не понимает уже корректный ключ.

В плане остались старые MGR, MDS или lockbox-пользователи

Сопоставьте записи с действующими службами, удалёнными узлами и зашифрованными OSD. Старое имя не доказывает, что ключ никому не нужен. Особенно опасно удалять client.osd-lockbox.* по маске: ошибка может проявиться только при следующем запуске OSD.

Удаление подтверждённо оставшейся записи давно выведенной службы — отдельная операция. Если происхождение ключа не установлено, сохраните его и разберите соответствие устройств и учётных записей до продолжения.

Нужно отменить подготовленный клиентский ключ

Для ещё не завершённой клиентской ротации предусмотрена штатная отмена. В примере client.example нужно заменить точным именем пользователя:

/usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys \
  --abort-staged-key client.example --apply

Помощник вернёт прежний текущий ключ в управляемые копии, пока оба ключа ещё действительны. Переподключите клиентов обратно с этим ключом, включая внешние системы и сохранённые копии. Затем подтвердите отмену:

/usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys \
  --confirm-abort-clients-refreshed client.example --apply

Это процедура отмены подготовленного ключа. Она не является универсальным откатом уже подтверждённых замен или перехода Tentacle → Squid. Если финальное ограничение уже лишило администратора доступа, нужен отдельный план восстановления через консоль и MON с учётом сохранившихся ключей.

Старый клиент пока нельзя обновить

Оставьте его ключ неизменным и сохраните возможность работы со старым шифром. Для CephFS альтернативой может быть совместимый ceph-fuse или файловый шлюз, но совместимость и изменения в эксплуатации нужно проверить отдельно.

Предупреждение можно временно приглушить, например на неделю:

ceph health mute AUTH_INSECURE_CLIENT_KEY_TYPE 1w

Это только изменение отображения. Уязвимый механизм продолжает использоваться. Зафиксируйте владельца клиента и срок обновления; не считайте HEALTH_OK с приглушёнными проверками доказательством устранения проблемы.

Cephx уже отключён, но сообщения всё равно есть

Проверки вычисляются по сохранённым ключам и настройкам шифров даже при auth_cluster_required, auth_service_required и auth_client_required, установленных в none. Отключение cephx не убирает эти причины.

Для такого кластера предусмотрен отдельный сценарий в документации Proxmox. Не выполняйте клиентский этап этой инструкции автоматически и не включайте или отключайте аутентификацию попутно: изменение метода требует переподключения клиентов. Перед возвратом cephx необходимо проверить совпадение ключей у служб и клиентов с базой аутентификации.

После Tentacle выросло потребление META на старых OSD

В известных проблемах перехода описан рост метаданных у некоторых OSD, созданных ещё на Octopus или раньше; проблема отмечена и для Tentacle 20.2.4. Если изменилась доступная ёмкость, сравните колонку META в ceph osd df с прежними значениями.

Это отдельная проблема хранения, не ошибка cephx. Не удаляйте данные и не пересоздавайте OSD только ради освобождения места. Компактация и изменение организации RocksDB требуют отдельного плана с оценкой нагрузки и резерва ёмкости.

Как убедиться, что обновление и миграция закончены

ceph -s
ceph health detail
ceph versions
pveceph auth status
ceph mon dump

Проверка считается завершённой, когда выполнены все относящиеся к вашему сценарию условия:

• Все обновляемые демоны работают на Tentacle, штатные MON присутствуют в кворуме, OSD находятся в up/in, данные доступны.
• После полной ротации нет незавершённых pending-ключей, а помощник не показывает оставшихся обязательных действий.
• В карте MON значения auth_service_cipher, auth_preferred_cipher и список auth_allowed_ciphers соответствуют завершённому переходу на aes256k.
• Предупреждения не скрыты приглушением. Допустимое ожидание истечения старых rotating service keys отслеживается отдельно.
• Проверены новые подключения: запуск тестовой ВМ с RBD, доступ контейнера к диску, запись и чтение файла на CephFS, подключение внешних клиентов.
• После изменений успешно выполнена резервная копия и проверено её восстановление в отдельную тестовую ВМ.
• Сняты временные флаги обслуживания, а журналы миграции и резервные копии ключей защищены от постороннего доступа.

Если нужна помощь с конкретным сбоем, подготовьте версии Proxmox и Ceph, вывод ceph -s, ceph health detail, ceph versions, pveceph auth status и точный этап остановки помощника. Укажите типы клиентов, наличие CephFS, внешних MON и зашифрованных OSD. Секретные ключи и журнал миграции в публичную диагностику не включайте.