Забытый пароль root на сервере RHEL 9 звучит как катастрофа, но на деле решается за пять минут без загрузочных флешек и переустановок - средствами самого дистрибутива. Ключ к процедуре - параметр rd.break, который останавливает загрузку ровно в тот момент, когда корневая файловая система уже найдена, но ещё не смонтирована как основная. Разбираем полный маршрут: редактирование записи GRUB2, работа в emergency-оболочке, смена пароля с учётом chroot и обязательный relabel SELinux, без которого система может так и не пустить вас внутрь после перезагрузки.
Почему именно rd.break и как это работает
Параметр rd.break обрабатывается dracut на ранней стадии загрузки: initramfs находит корневой раздел, монтирует его в /sysroot только для чтения и прерывает загрузку, отдавая emergency-оболочку с правами root без запроса пароля. Именно беззапросность делает процедуру спасения возможной - аутентификация приостанавливается до того, как система успевает её спросить.
Альтернативный путь init=/bin/sh работает и на RHEL, но имеет два минуса: он грубее к состоянию сервисов и требует помнить о ручном remount. Rd.break аккуратнее: корень гарантированно смонтирован в /sysroot, и последовательность дальнейших шагов стандартизована в документации Red Hat, что означает одинаковое поведение на любом сервере семейства - RHEL, Rocky, Alma, Oracle Linux.
Редактирование загрузочной записи в GRUB2
Включение сервера начинается с нажатия стрелки вверх в меню GRUB, чтобы меню не проскочило на дефолтную запись. Выбрав нужную систему, нажимаем e - открывается редактор записи с параметрами загрузки. В строке linux добавляем в конец rd.break - и только его: если в строке есть console-параметры, они остаются как есть. Загрузка продолжается по Ctrl-X.
Через несколько секунд загрузка останавливается, и появляется приглашение switches shell с приглашением ввода. Пароль не запрашивается - это и есть целевое состояние процедуры. Для уверенности стоит проверить, что корень смонтирован: mount | grep sysroot покажет файловую систему в режиме ro - только для чтения, что и предстоит исправить на следующем шаге.
Пошаговая процедура от remount до passwd
Оболочка получена, теперь выполняем канонические пять команд. Первая: mount -o remount,rw /sysroot - переводим корень в режим записи, потому что без этого passwd не сможет изменить файл с теневыми паролями. Вторая: chroot /sysroot - переходим внутрь корневой файловой системы, чтобы все дальнейшие команды работали как в обычной системе. Третья: passwd root - задание нового пароля с подтверждением. Четвёртая: touch /.autorelabel - создаём маркер для SELinux, о котором подробно в следующем разделе. Пятая: exit дважды - сначала выходим из chroot, затем из emergency-оболочки, после чего загрузка продолжается с новым паролем.
Каждая команда отвечает за свой слой защиты, и пропуск любой из них воспроизводится отказом: без remount пароль не записывается, без chroot passwd меняет пароль не в том дереве, без relabel система может не пустить вход по SSH даже с корректным паролем. Пятнадцать минут практики - и последовательность запоминается как единой короткой песней.
SELinux relabel как обязательный финальный шаг
Ключевая особенность RHEL, из-за которой процедура сброса пароля отличается от остальных дистрибутивов - SELinux. При смене пароля вне обычного контекста загрузки файл /etc/shadow получает новый контекст безопасности, и после перезагрузки политика SELinux отклоняет обращения к нему: система выглядит работоспособной, пароль вроде верный, но логин не проходит ни локально, ни по SSH.
Лечение - маркер touch /.autorelabel: при следующей загрузке система автоматически перемаркирует файловые системы, присваивая всем файлам правильные контексты. Процесс занимает от пары секунд на SSD до нескольких минут на больших FS - на экране виден прогресс, и пугаться его не стоит. В системах, где relabel по какой-то причине не отработал, применяется временный параметр загрузки selinux=0 для диагностики - но это запасной выход, а не часть процедуры: перезагружаться с отключённым SELinux на проде дольше одного раза недопустимо.
Если система не грузится дальше и разбор отказов
Три типичных осложнения встречаются чаще других. Первое - после exit загрузка виснет или уходит в emergency shell уже по своей причине: это означает, что проблема с паролем была лишь вершиной, а настоящая неполадка лежит глубже, и диагностике поможет журнал предыдущей загрузки. Второе - опечатка в rd.break или лишний пробел в параметрах: GRUB2 игнорирует неизвестное, и загрузка идёт штатно, минуя оболочку; проверяется повторным редактированием записи. Третье - на загрузчике стоит пароль GRUB, и редактирование недоступно: тогда путь лежит через спасательную флешку с chroot, и пароль меняется той же passwd из смонтированной системы.
Четвёртый случай тоньше: системы с заблокированной консолью через дополнительные механизмы защиты (например, в защищённых контурах) могут требовать пароль даже в emergency-режиме - это осознанная настройка безопасности, и обойти её без физического доступа не получится. Именно о таких сценариях стоит помнить при проектировании инфраструктуры: чем жёстче защита, тем важнее процедуры управления через консольные серверы и IPMI.
Защита от несанкционированного сброса
Обратная сторона простоты процедуры - физический доступ к консоли означает полный доступ к системе. Для серверов в неконтролируемых помещениях применяется пароль на сам GRUB2: утилита grub2-setpassword задаёт пароль, без которого редактирование записей загрузчика запрещено. Проверка проста: попытка нажать e в меню показывает запрос пароля. Комбинация с шифрованием диска LUKS закрывает сценарий полной компрометации - даже загрузившись в rd.break, злоумышленник получит не систему, а запрашивающий пароль раздел.
Именно эти две меры - GRUB password и шифрование - есть в контрольных списках серьёзных аудиторов, и разумный инженер закладывает их до первой утраты пароля, потому что после первой утраты обычно уже поздно что-то охранять.
Итоговая памятка дежурного инженера
Финальная шпаргалка выглядит так: стрелка в GRUB - e - rd.break в конец строки linux - Ctrl-X - remount rw /sysroot - chroot /sysroot - passwd - touch /.autorelabel - exit - exit. Пять минут на выполнение, ещё две на перезагрузку с relabel, и сервер снова управляем. Хранить памятку стоит не в голове, а в runbook: процедура нужна ровно раз в год-два, и именно к этому моменту из памяти выветривается всё, кроме уверенности, что "где-то это было в документации".
Особенности на виртуальных машинах и в облаках
Виртуализация вносит свои поправки. На KVM-машинах с virt-консолью меню GRUB доступно из VNC-окна или из virt-manager, и вся процедура выполняется привычным образом. На облачных образах RHEL меню загрузчика скрыто по умолчанию, и попасть в него помогает параметр grub2 конфигурации или удержание клавиши при загрузке - если консоль вообще доступна. В облаках без консольного доступа механизм другой: серийная консоль провайдера - инструмент для этих случаев, и заранее стоит проверить, работает ли она, потому что в момент утраты пароля проверять поздно.
Второй облачной нюанс: многие облачные образы используют не пароль root, а ssh-ключи, и задача переформулируется - добавить новый ключ через cloud-init или rescue-режим провайдера, что легче смены пароля. Третий нюанс - шаблоны виртуальных машин: инженер, готовящий шаблон, закладывает в него и emergency-порядок, чтобы унаследованные машины спасались тем же путём без сюрпризов.
Автоматизация и предотвращение утраты паролей
Лучшая авария - не случившаяся, поэтому зрелая команда предотвращает сам сценарий. Пароль root хранится в менеджере секретов команды, доступ к нему разделён по ролям, и утрата его одним человеком не блокирует остальных. Несколько человек владеют emergency-доступом, и перекрёстная проверка прав проводится раз в квартал. Ключи SSH на администраторских аккаунтах уменьшают потребность в пароле до аварийных сценариев, а аварийные сценарии регулярно тестируются на стенде.
Практика ttl для паролей выглядит разумно, но с root-паролем продакшена осторожность в другую сторону: слишком частая смена пароля увеличивает риск утраты, и баланс между свежестью и запоминаемостью выбирается командой осознанно. Записанная один раз и проверенная процедура из этой статьи - вот что делает такие решения безопасными: даже ошибочный пароль перестаёт быть событием.
Проверка процедуры на стенде
Прежде чем путь через rd.break понадобится на проде, его стоит однократно пройти на стенде - на любой тестовой машине RHEL 9, которую не жалко перезагрузить. Знакомое меню, знакомые шаги, знакомая скорость - и руках остаётся память о деталях, от которых зависит успех: где именно редактировать строку linux, как выглядит приглашение emergency shell, сколько длится autorelabel. Час тренировки на стенде экономит драгоценные минуты на проде и убирает единственный настоящий риск процедуры - неуверенность исполнителя.
История из практики
Классический случай: унаследованный сервер, команды прежних владельцев больше нет, пароль root неизвестен, доступ остался у приложения, и возникла задача настройки брандмауэра. Двадцать минут - редактирование записи GRUB, смена пароля, autorelabel, вход, и сервер снова управляем. Без процедуры это была бы заявка на восстановление системы с потерей времени и рисками данных; с процедурой - рядовая задача дежурства. Такие истории встречаются в каждой инфраструктуре, и у всех у них одинаковый урок: методы аварийного доступа должны быть известны заранее, проверены и доведены до состояния привычки.
Короткий итог для памяти
Rd.break существует именно для таких случаев, когда стандартные механизмы недоступны, и его сила - в предсказуемости: последовательность одинакова на любом сервере семейства, задокументирована вендором и не зависит от содержимого системы. Знание этой процедуры входит в базовый набор навыков каждого администратора RHEL, и её краткая версия - семь шагов на экран консоли - заслуживает места на стене серверной рядом с прочими аварийными памятками.
Разбор реального случая целиком
Характерный кейс: после смены команды унаследованный сервер RHEL 9 понадобился для настройки, а пароль root жил только в голове уволившегося инженера. Под рукой - доступ в IPMI с серийной консолью, и дальше всё по памятке: перезагрузка через IPMI, перехват меню GRUB по консоли, rd.break, remount, chroot, passwd, маркер relabel, exit. Перезагрузка с автоперемаркировкой заняла четыре минуты, новый пароль вошёл с первого раза, и вечер закончился обычными задачами вместо проекта восстановления сервера. Полная стоимость решения - пятнадцать минут, из которых двенадцать - перезагрузки.
Сравните с альтернативами: заявка в поддержку вендора длится дни, переустановка означает потерю настроек и простой сервиса, а спасательная флешка требует физического доступа к серверу в дата-центре. Именно поэтому знание процедуры стоит дороже любых инструментов - она не требует ничего, кроме консоли и семи строк из памятки.
Пусть эта памятка так и останется теорией в вашем runbook, но однажды вы будете благодарны себе за те пятнадцать минут, когда заполняли её спокойным вечером, а не искали в три часа ночи.
Семь шагов процедуры умещаются на наклейку для монитора, и в серверных, где такие наклейки живут годами, аварийная смена пароля root перестаёт быть событием - она становится рутиной из разряда "перезапустить зависший сервис".
Семь строк памятки - и любые унаследованные, потерянные и забытые пароли перестают быть проблемой инфраструктуры, оставаясь лишь вопросом пяти минут и спокойных рук.
Спокойных дежурств!
На этом тема закрыта окончательно.