Пароль суперпользователя обычно теряется в самый неудобный момент: в конце квартала, когда надо срочно поднять сервис, или на следующий день после ухода человека, который один его знал. Хорошая новость в том, что в RHEL 9 предусмотрен штатный маршрут возврата доступа без сторонних загрузочных носителей и без извлечения дисков. Достаточно консоли, физической или удалённой, четырёх команд в аварийной оболочке и понимания двух ловушек, о которые спотыкаются даже опытные инженеры: корень смонтирован только для чтения, а SELinux без метки autorelabel отвергнет свежий секрет на следующем старте. Ниже разобран весь маршрут, с настоящими сообщениями системы, разбором обеих ловушек и мерами защиты от посторонних, у которых тоже есть доступ к консоли.
Инициализация через initramfs и точка в загрузке где срабатывает rd.break
Ядро Linux само по себе не умеет монтировать корневую файловую систему. Сначала GRUB передаёт ему два файла, vmlinuz и сжатый архив initramfs, внутри которого собраны модули дисковых контроллеров, драйверы XFS, утилиты для работы с LVM и крошечная ранняя пользовательская среда. Эта среда находит корень, монтирует его в каталог /sysroot и только потом передаёт управление systemd основной системы. Параметр rd.break, дописанный в командную строку ядра, приказывает dracut, сборщику initramfs, задержаться на финальном шаге раннего старта и открыть оболочку. Никакого пароля эта оболочка не спрашивает: PAM, учётные записи и журналы основной системы ещё не работают. Реальный корень к этому моменту уже найден и смонтирован в /sysroot, но строго в режиме только чтения.
В меню GRUB нажимают клавишу e, находят строку, начинающуюся со слова linux, и дописывают rd.break в её конец через пробел. В RHEL 9 строка одна и та же на машинах с Legacy BIOS и с UEFI, отличается лишь перечень параметров вроде root=UUID. Запуск отредактированного пункта выполняется сочетанием Ctrl и X. Правка живёт одну загрузку: конфигурация GRUB на диске не меняется, поэтому после успешной процедуры ничего откатывать не нужно. Серверные удалённые консоли, от iDRAC до IPMI, передают нажатия так же, как физическая клавиатура, так что присутствие рядом со стойкой не обязательно. В облаке ту же роль играет последовательная консоль провайдера, а самый тяжёлый случай, когда консоли нет вовсе, решается подключением диска к вспомогательной виртуальной машине.
Каталог /sysroot придуман самой ранней средой: в повседневной работе основной системы такого пути нет. Все команды процедуры обращаются именно к нему, и путаница с путями здесь почти исключена. Побочно стоит знать, что параметром rd.break пользуются и при других поломках раннего старта, от недоступного корневого тома до проверки свежесобранных модулей загрузки. Приём универсальный, а не только про забытые секреты.
Пошаговый порядок работы от правки меню GRUB до passwd в chroot
Сама процедура короткая и умещается в семь шагов, порядок которых лучше не менять:
- перезагрузить сервер и в меню GRUB нажать клавишу e для правки выбранного пункта;
- в строке linux дописать rd.break и запустить загрузку сочетанием Ctrl и X;
- в аварийной оболочке перемонтировать корень командой mount -o remount,rw /sysroot;
- войти в окружение основной системы командой chroot /sysroot;
- задать новый секрет командой passwd root;
- создать метку touch /.autorelabel для переразметки SELinux;
- дважды ввести exit, чтобы закрыть chroot и продолжить обычную загрузку.
Консольная сессия целиком выглядит так:
switch_root:/# mount -o remount,rw /sysroot
switch_root:/# chroot /sysroot
sh-4.4# passwd root
New password:
Retype new password:
passwd: password updated successfully
sh-4.4# touch /.autorelabel
sh-4.4# exit
switch_root:/# exitПервый exit закрывает chroot, второй отпускает dracut, и машина продолжает нормальный старт с уже перемонтированным корнем. Если что-то пошло не так на любом шаге, простая перезагрузка возвращает всё в исходное состояние: аварийная оболочка ничего не меняет сама, каждая команда выполняется вручную. Политика качества паролей из /etc/security/pwquality.conf работает и внутри chroot: чересчур простой вариант passwd отвергнет сообщением BAD PASSWORD и попросит придумать что-нибудь посерьёзнее. Практично сразу задать секрет, который не придётся менять на следующей неделе, и держать под рукой парольную фразу диска, если корень зашифрован.
Ошибка Authentication token manipulation error говорит о пропущенном remount
Ловушка первая ждёт на шаге с passwd. Если пропустить перемонтирование, команда завершится сообщением "passwd: Authentication token manipulation error", и никакие повторы не помогут: /etc/shadow лежит на файловой системе, открытой только для чтения, и ядро отказывается принимать запись. Режим только чтения здесь не каприз, а осознанное решение: initramfs намеренно оставляет корень в максимально безопасном состоянии, чтобы ручные действия не меняли файлы без явного намерения. Быструю проверку даёт команда mount | grep sysroot: в параметрах монтирования будет виден флаг ro. После mount -o remount,rw /sysroot флаг сменится на rw, а журнал XFS, типовой файловой системы RHEL 9, будет воспроизведён автоматически. Если корень живёт на логическом томе, устройство будет называться вроде /dev/mapper/vg_root-lv_root, но команда от этого не меняется: /sysroot остаётся одним и тем же каталогом. На системах с ext4 разница только в имени утилиты проверки файловой системы, сама логика одинакова.
Перемонтирование живёт до перезагрузки: если машину перезапустить до смены секрета, корень снова окажется в режиме только чтения, и всю последовательность придётся пройти заново.
Роль файла autorelabel и восстановление контекстов SELinux
Ловушка вторая коварнее первой, потому что проявляется уже после успешной, казалось бы, процедуры. В RHEL 9 SELinux по умолчанию работает в режиме enforcing. Оболочка внутри initramfs политикой не ограничена, поэтому passwd переписывает /etc/shadow с контекстом, отличающимся от положенного shadow_t. На следующем старте проверяющая утилита unix_chkpwd не сможет прочитать файл, и система откажет во входе даже с правильным секретом: консоль ответит "Login incorrect", графический экран вернётся к приглашению, ssh покажет "Permission denied". Метка touch /.autorelabel исправляет именно это: при следующем старте система автоматически запускает полную переразметку файловой системы, показывает на экране имена обрабатываемых файлов, а по завершении перезагружается ещё раз сама. Переразметка идёт тем дольше, чем больше файлов на диске: на файловом сервере счёт может идти на десятки минут, и питание в этот момент отключать нельзя, иначе часть контекстов останется старой.
Компромиссный вариант для тех, кто спешит: дописать в строку ядра рядом с rd.break ещё и enforcing=0, тогда метка не обязательна, но после входа стоит вернуть файлу правильный контекст командой restorecon -v /etc/shadow, а затем включить режим обратно командой setenforce 1. Текущий режим подскажет getenforce. Полезно заглянуть и в /etc/selinux/config: там должна остаться строка SELINUX=enforcing; если политику когда-то отключали, отказ во входе после смены секрета будет иметь другую причину, и метка не поможет вовсе. А правка командной строки в GRUB, как уже сказано, живёт одну загрузку и сама не сохраняется.
Как это выглядит под капотом: при старте служба переразметки проходит по всем файлам и присваивает им контексты из активной политики. Для большинства машин это сотни тысяч файлов и несколько минут ожидания, для больших файловых серверов с миллионами мелких файлов счёт уходит за полчаса. Прерывать процесс нельзя: сама файловая система не портится, но контексты останутся частично старыми, вход так и будет закрыт, и всю работу придётся повторить.
Шифрование корня LUKS и логические тома LVM в процедуре возврата доступа
Установщик RHEL 9 по умолчанию размещает корень на логическом томе LVM, и на процедуру это не влияет: /sysroot всего лишь каталог, за которым может стоять и /dev/mapper/vg_root-lv_root, и обычный раздел. С шифрованием LUKS история другая. Если корень зашифрован и фраза вводится вручную, диск запросит её раньше, чем случится остановка загрузки, поэтому владелец вводит её как обычно, и дальше всё идёт по знакомым шагам. Если фраза неизвестна, /sysroot так и останется запертым, и никакая аварийная оболочка не поможет: шифрование честно выполняет свою работу даже против самого владельца сервера с консолью. Отсюда практический вывод: перед началом работы стоит убедиться, что фраза от диска доступна, а если потеряна, то содержимое придётся возрождать из резервных копий. Понятнее становится и роль загрузочного раздела: /boot не шифруют, потому что загрузчику нужно прочитать ядро и initramfs, и это же делает возможным весь маршрут через rd.break. Зато файлы на зашифрованном корне остаются закрытыми без фразы, что для большинства компаний важнее самого секрета суперпользователя.
Защита сервера от несанкционированной смены пароля суперпользователя
Обратная сторона удобства в том, что тот же маршрут доступен любому, кто добрался до консоли и может перезагрузить машину. Замыкают его несколько барьеров, работающих в связке. Команда grub2-setpassword записывает хеш пароля загрузчика в /boot/grub2/user.cfg, после чего правка пунктов меню требует аутентификации; пароль этот придётся помнить, иначе путь через GRUB закроется и останется только загрузочный носитель. Пароль микропрограммы платы закрывает меню выбора устройства старта, не давая загрузиться со своей флешки. Шифрование диска делает смену секрета бессмысленной, пока не известна фраза LUKS. Наконец, физическая безопасность и контроль удалённых консолей остаются главными: у кого экран и кнопка питания, у того и фактический контроль над машиной. Полезно понимать, как выглядела бы несанкционированная процедура: журналы основной системы в ней не пополняются, ведь systemd не стартует. После возврата доступа разумно сверить время изменения /etc/shadow с журналом пропусков и списком тех, кто работал с консолью в спорный период. Централизованный сбор журналов напрямую проблему не решает, но по молчанию машины в системе мониторинга легко заметить сам факт незапланированной перезагрузки.
Пароль загрузчика хранят в корпоративном менеджере секретов вместе с фразами LUKS и паролями микропрограмм: три ключа от одной двери должны лежать в одном списке, иначе через год дверь окажется запертой для самих владельцев.
Чеклист ловушек процедуры и способы их избежать
Свод типичных ошибок короткий, но каждый пункт в нём стоит дорого. Пропущенное перемонтирование даёт "Authentication token manipulation error" и лечится одной командой. Забытая метка autorelabel оборачивается отказом во входе при верном секрете; исправляется повторением процедуры до конца, а не новыми попытками входа. Секрет с национальными символами рискует не совпасть с тем, что набирается позже на полноценной системе: раскладка аварийной оболочки не всегда совпадает с настроенной, поэтому надёжнее ограничиться символами общей части раскладок. Прерванная по нетерпению переразметка может оставить часть контекстов старой, и следующий старт тоже не впустит; экран с прогрессом нужно просто дождаться, машина перезагрузится сама. Правка в GRUB не сохраняется, поэтому после неудачной попытки параметр rd.break дописывают заново. И последнее: процедуру проводят в согласованное окно обслуживания, потому что переразметка на нагруженном хранилище задержит готовность сервера.
Если вход не заработал и после переразметки, процедуру повторяют целиком: на втором проходе обычно выясняется, что метка не была создана или секрет набран с опечаткой. Проверять обе вещи по журналам бессмысленно, у аварийной сессии их нет, поэтому надёжнее просто пройти шаги заново, не пропуская touch /.autorelabel.
Вся дорога до нового секрета занимает минут десять плюс время переразметки. Две ловушки, режим только чтения и метка autorelabel, превращают простую операцию в головную боль только тогда, когда о них не знают. Теперь порядок известен: remount, passwd, autorelabel, exit. Тот же маршрут без изменений работает в Rocky Linux, AlmaLinux и Oracle Linux, потому что под ними тот же dracut, тот же GRUB и тот же SELinux. А консоль сервера остаётся границей доверия: тот, кто видит экран и может перезагрузить машину, получает шанс на права root, и защищать в первую очередь стоит именно доступ к ней.