Debian 13: Відновлення доступу root через rescue mode — не погіршіть ситуацію

Єдині правила, які мають значення в rescue mode

Rescue mode — це скальпель, а не бензопила. Мета вузька: відновити контрольований адміністративний доступ, а потім акуратно вийти.
Не намагайтесь «пофіксити все підряд». Саме так інциденти з root‑доступом перетворюються на багатоденні відновлення.

Правило 1: Доведіть, що ви працюєте з правильним сервером

Середовища відновлення сповнені пасток, бо легко змонтувати диски з різних систем.
Перед будь‑якими змінами підтвердьте hostname, ідентифікатори дисків і кореневу файлову систему, яку ви збираєтеся ремонтувати.
Якщо ви не можете це довести — ви здогадуєтесь. Здогадки коштують дорого.

Правило 2: За замовчуванням монтуйте в режимі лише для читання, поки не визначите помилку

Багато «невдач з root‑доступом» насправді не пов’язані з автентифікацією. Це збій монтовання під час завантаження, пошкоджений initramfs, зламані модулі PAM,
неправильні права на /etc/shadow, або прострочений запит шифрування диска, який ви ніколи не бачите на безголових серверах.

Спочатку монтуйте read‑only. Збирайте докази. Потім перемонтуйте в режим запису лише для тієї однієї зміни, яка вирішує корінну причину.

Правило 3: Віддавайте перевагу мінімальним і відкатним змінам

Редагування PAM‑стеків, sudoers або конфігурації SSHD в паніці — спосіб заблокувати себе двічі.
Якщо потрібно змінювати автентифікацію, скористайтесь перевіреним шляхом: встановіть тимчасовий пароль root, знову включіть відомого адміністраторського користувача та заплануйте коректне виправлення.

Правило 4: Ведіть судовий (forensic) журнал дій

Ви забудете, що робили. Колега запитає. Ваш майбутній я прокляне вас.
Ведіть нотатки: що було зламано, які команди ви запускали, які файли редагували. Навіть грубий текстовий лог у /root/rescue-notes.txt коштує золота.

Жарт №1: Rescue mode схожий на хірургію — стерильне поле, чисті інструменти і ні в якому разі «побачимо, що станеться, якщо я тут щось ткну».

Цікаві факти та контекст (чому Debian веде себе так)

• Один корінь на систему: Традиційний Unix‑режим single‑user виник задовго до systemd і був призначений для локального консолі‑відновлення, коли мультикористувацькі сервіси не працюють.
• systemd: emergency vs rescue: На системах з systemd target rescue намагається підняти мінімальну систему; emergency ще менше — часто це оболонка, схожа на initramfs, з меншим набором монтажів.
• Root‑акаунт може бути заблокований за задумом: Багато інсталяцій Debian покладаються на sudo і можуть блокувати root, встановивши спеціальний хеш пароля. Це не баг — це політика.
• PAM — це стек, не вимикач: Pluggable Authentication Modules дозволяють змінювати методи автентифікації без переписування програм, а отже одна зла ключова рядок може зламати все.
• /etc/shadow не завжди був окремим: Розділення між /etc/passwd і /etc/shadow — еволюція безпеки, щоб хеші паролів були приховані від непривілейованих користувачів.
• Initramfs — це маленька ОС: Сучасне Linux‑завантаження проходить через початкову RAM‑файлову систему, яка завантажує драйвери, розшифровує диски, активує LVM і монтує реальний root. Якщо ця маленька ОС некоректна — «проблема root» лежить вище.
• GRUB став стандартом не даремно: Здатність GRUB редагувати параметри ядра під час завантаження рятує в критичних випадках — і це ще одна причина, чому фізичний доступ до консолі важливий.
• Опції монтування можуть вас заблокувати: Один неправильний рядок у /etc/fstab може кинути систему в emergency mode, навіть якщо паролі правильні.

Один вислів, який варто пам’ятати під тиском: «Надія — це не стратегія.» — General Gordon R. Sullivan.

Швидкий діагностичний плейбук (перевірка 1/2/3)

Коли ви стоїте за консоллю з проблемною системою, найшвидший шлях — класифікувати відмову. Не за відчуттями, а за сигналами.

Перевірка 1: Це відмова автентифікації чи відмова завантаження/монтовання?

• Якщо ви бачите запит логіну, але root/sudo не проходять: ймовірно стан акаунту, PAM, права на shadow або sudoers.
• Якщо ви ніколи не доходите до нормального логіна і опиняєтесь в emergency mode: ймовірно fstab, initramfs, активація LUKS/LVM, помилки файлової системи.
• Якщо система працює, але ви не можете зайти віддалено: ймовірно мережа, конфіг sshd, ключі хоста, брандмауер або права ключів.

Перевірка 2: Чи коренева файлова система ціла та монтується?

Перш ніж торкатися автентифікації, перевірте, чи можна змонтувати реальний root. Якщо не можна, зупиніться й діагностуйте зберігання.
Виправляти паролі на неправильному mountpoint — класична самосаботажна помилка.

Перевірка 3: Чи можете ви відтворити помилку за журналами?

В rescue mode змонтуйте root у режимі read‑only і перегляньте /var/log та журнал. Якщо помилка повторювана і зафіксована — ви зможете виправити її точно.
Якщо логу немає, ви все одно часто можете вивести причину з конфігураційних зсувів і помилок завантаження.

Способи зайти в rescue mode на Debian 13

1) GRUB: редагування команд рядка ядра (консольний доступ)

Якщо ви можете дійти до GRUB, зазвичай можна отримати доступ до відновлення. Виділіть звичайний пункт завантаження, натисніть e і додайте:
systemd.unit=rescue.target або systemd.unit=emergency.target до рядка Linux.

Rescue target зазвичай піднімає більше системи (включно з деякими монтажами). Emergency target мінімальний і корисний, коли монтажі зламані.

2) Інсталятор Debian: «Rescue a broken system»

Завантажте ISO інсталятора (або netinst) і оберіть опцію rescue. Він може виявити встановлені системи, змонтувати їх і запропонувати chroot.
Це часто найчистіший шлях на безголових серверах, якщо у вас є віддалений KVM або віртуальна консоль.

3) Хмара/VM: приєднати rescue ISO або використати образ провайдера

У продакшені ви можете не мати фізичного доступу. Використайте консоль гіпервізора та завантажте rescue ISO або режим рятування від провайдера.
Та сама дисципліна: ідентифікуйте диски по стабільних ідентифікаторах, монтуйте read‑only спочатку та обережно ставтесь до зашифрованих томів.

Карта тріажу: що саме ви виправляєте

«Відновити доступ root» може означати кілька різних проблем. Класифікуйте її перед дією.

A. Root‑акаунт заблокований або пароль невідомий

Root може бути заблокований цілеспрямовано, або ви успадкували систему, де ніхто не знає пароль.
Виправлення зазвичай: змонтуйте систему, chroot, встановіть новий пароль або знову увімкніть sudo для відомого адміністратора.

B. sudo зламався (синтаксис, права, неправильний файл)

Неправильний запис у sudoers може зламати всю роботу sudo. Це виглядає як «немає root‑доступу», але насправді це помилка валідації конфігурації.
Виправлення: перевіряйте через visudo (або ремонтуйте обережно) з chroot.

C. PAM / стек автентифікації зламаний

Якщо модулі PAM були видалені, неузгоджені або неправильно налаштовані, логіни будуть відмовляти навіть при правильних паролях.
Виправлення зазвичай — відновлення потрібних пакетів/конфігів; уникайте «вимикання PAM» хаків.

D. Система опускається в emergency mode (fstab, fsck, пристрій не знайдено)

Це не проблема автентифікації. Це проблема залежностей завантаження. Виправте монтаж, UUID або проблему файлової системи спочатку.

E. Зашифрований root або LVM не активується

Якщо initramfs не може розблокувати LUKS або зібрати LVM, ваш root ніколи не з’явиться. Виправлення у initramfs, crypttab, метаданих LVM або відсутніх драйверах.

F. Віддалений доступ відсутній (sshd, ключі, брандмауер), але локальний root існує

Іноді машина в порядку, а зламався лише віддалений доступ. Не скидайте root лише через відсутність SSH.
Виправляйте SSH і мережу мінімальними змінами.

Практичні завдання (команди, виводи, рішення)

Це ті завдання, які я реально виконую в сценаріях rescue. Кожне містить: команду, типовий вивід і рішення, яке ви приймаєте.
Команди припускають середовище rescue з правами root. Промпт хоста фіксується відповідно до ваших вимог.

Завдання 1: Ідентифікуйте диски та розділи (не гадати)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE UUID                                 MOUNTPOINTS
sda         480G disk
├─sda1      512M part vfat   7C2A-1F0B                            /boot/efi
├─sda2        2G part ext4   2a9c1f7b-1c77-4e7b-8f4c-2df9c5a2d9c1 /boot
└─sda3    477.5G part crypto_LUKS 3a0b6d9b-... 
  └─cryptroot 477.5G crypt LVM2_member 8h2KqX-...
    ├─vg0-root  80G lvm  ext4   7f6b9e0c-...                      /
    └─vg0-var  200G lvm  xfs    4f0d2c1a-...                      /var

Значення: Ви бачите, чи маєте справу з простими розділами, LUKS, LVM і які типи FS потрібні інструменти (ext4, xfs, btrfs).

Рішення: Якщо бачите LUKS/LVM‑шари, плануйте розблокування і активацію перед монтуванням. Якщо root FS не очевидна — зупиніться і змапте її, перш ніж щось редагувати.

Завдання 2: Підтвердьте, що ядро бачило очікуване сховище

cr0x@server:~$ dmesg -T | grep -E "sd[a-z]|nvme|dm-|crypt|I/O error" | tail -n 20
[Mon Dec 30 01:12:03 2025] nvme nvme0: pci function 0000:01:00.0
[Mon Dec 30 01:12:03 2025] nvme0n1: p1 p2 p3
[Mon Dec 30 01:12:04 2025] device-mapper: crypt: dm-0: set key succeeded

Значення: Відсутність I/O‑помилок — добре. Якщо бачите таймаути або помилки читання, можливо ви маєте справу з деградуючим диском, а не з автентифікацією.

Рішення: Якщо сховище нестабільне — мінімізуйте записи. Віддавайте перевагу read‑only монтажам, зробіть імідж/снапшот якщо можливо, і плануйте заміну замість «лікування конфігів».

Завдання 3: Якщо використовується LUKS, розблокуйте явно (і перевірте)

cr0x@server:~$ cryptsetup luksOpen /dev/sda3 cryptroot
Enter passphrase for /dev/sda3:

cr0x@server:~$ cryptsetup status cryptroot
/dev/mapper/cryptroot is active.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/sda3
  sector size:  512
  offset:  32768 sectors
  size:    1000204288 sectors
  mode:    read/write

Значення: Mapper‑пристрій існує і активний. mode показує, чи він записуваний на цьому шарі.

Рішення: Якщо розблокування не вдається — не брутфорсьте. Перевірте, що ви на правильному пристрої, перевірте налаштування клавіатури в rescue‑середовищі і підтвердіть джерело пароля.

Завдання 4: Активуйте LVM‑томи (якщо є)

cr0x@server:~$ vgscan
  Found volume group "vg0" using metadata type lvm2

cr0x@server:~$ vgchange -ay
  2 logical volume(s) in volume group "vg0" now active

Значення: Метадані LVM читаються і логічні томи активні.

Рішення: Якщо активація не вдається, перевірте pvs/vgs/lvs і розгляньте, чи відсутній PV (від’єднаний диск) або відфільтрований LVM конфіг.

Завдання 5: Монтуйте root спочатку в режимі read‑only (завжди)

cr0x@server:~$ mount -o ro /dev/vg0-root /mnt
cr0x@server:~$ mount | grep " /mnt "
/dev/mapper/vg0-root on /mnt type ext4 (ro,relatime)

Значення: Root filesystem монтується чисто в режимі read‑only.

Рішення: Якщо mount видає «wrong fs type» або «bad superblock», зупиніться і виконайте перевірку файлової системи відповідними інструментами (наступні завдання). Не починайте редагувати /etc, якщо FS не здоровий.

Завдання 6: Змонтуйте допоміжні файлові системи (boot, EFI, var) правильно

cr0x@server:~$ mount -o ro /dev/sda2 /mnt/boot
cr0x@server:~$ mount -o ro /dev/sda1 /mnt/boot/efi
cr0x@server:~$ mount -o ro /dev/vg0-var /mnt/var
cr0x@server:~$ findmnt -R /mnt
TARGET        SOURCE               FSTYPE OPTIONS
/mnt          /dev/mapper/vg0-root ext4   ro,relatime
/mnt/boot     /dev/sda2            ext4   ro,relatime
/mnt/boot/efi /dev/sda1            vfat   ro,relatime
/mnt/var      /dev/mapper/vg0-var  xfs    ro,relatime

Значення: Ваш chroot (пізніше) побачить ту ж розмітку, якої очікує встановлена ОС.

Рішення: Якщо /var окремо і не змонтований, журнали і стан автентифікації можуть виглядати «відсутніми», що веде до хибних висновків.

Завдання 7: Перевірте, що саме зламалося при останньому завантаженні (журнал)

cr0x@server:~$ journalctl --directory=/mnt/var/log/journal -b -1 -p err..alert --no-pager | tail -n 30
Dec 29 23:58:12 db13 systemd[1]: Failed to mount /data.
Dec 29 23:58:12 db13 systemd[1]: Dependency failed for Local File Systems.
Dec 29 23:58:12 db13 systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.

Значення: Це патерн помилки при завантаженні (монтаж через fstab), а не проблема з паролем.

Рішення: Виправте визначення монтовання перед тим, як чіпати акаунти користувачів. Інакше ви «відновите root», а система знову впаде в emergency mode.

Завдання 8: Огляньте й перевірте /etc/fstab безпечно

cr0x@server:~$ sed -n '1,200p' /mnt/etc/fstab
UUID=7f6b9e0c-...  /      ext4  defaults,errors=remount-ro  0 1
UUID=2a9c1f7b-...  /boot  ext4  defaults                   0 2
UUID=7C2A-1F0B     /boot/efi vfat umask=0077               0 1
UUID=deadbeef-...  /data  ext4  defaults                   0 2

Значення: Той рядок UUID=deadbeef... підозрілий, якщо його не існує.

Рішення: Порівняйте з blkid. Якщо UUID застарілий — або виправте його, або додайте nofail,x-systemd.device-timeout=10s для некритичних монтувань, щоб дозволити системі завантажитись.

Завдання 9: Перевірте UUID і мітки (ground truth)

cr0x@server:~$ blkid
/dev/sda1: UUID="7C2A-1F0B" TYPE="vfat" PARTUUID="..."
/dev/sda2: UUID="2a9c1f7b-1c77-4e7b-8f4c-2df9c5a2d9c1" TYPE="ext4" PARTUUID="..."
/dev/mapper/vg0-root: UUID="7f6b9e0c-..." TYPE="ext4"
/dev/mapper/vg0-var: UUID="4f0d2c1a-..." TYPE="xfs"

Значення: Якщо UUID в fstab відсутній у цьому списку — він не змонтується при завантаженні.

Рішення: Виправте неправильний ідентифікатор. Якщо диск цілеспрямовано відсутній (виведений із обслуговування), видаліть/закоментуйте монтування або позначте як nofail.

Завдання 10: Якщо цілісність файлової системи під сумнівом — перевіряйте її правильно

Для ext4 використовуйте fsck на відмонтованій файловій системі. Для XFS зазвичай використовуйте xfs_repair (і він вимогливий щодо відмонтування).

cr0x@server:~$ umount /mnt
cr0x@server:~$ fsck.ext4 -f /dev/vg0-root
e2fsck 1.47.0 (5-Feb-2023)
/dev/vg0-root: clean, 512345/5242880 files, 12345678/20971520 blocks

Значення: «clean» означає, що FS, ймовірно, не ваша проблема.

Рішення: Якщо він повідомляє про помилки і виправляє їх — перемонтуйте і повторно перевірте журнали. Якщо повідомляє про серйозну корупцію — пауза і розгляньте створення образу/відновлення з бекапів перед подальшими записами.

Завдання 11: Підготуйте chroot правильно (bind‑монтами)

cr0x@server:~$ mount /dev/vg0-root /mnt
cr0x@server:~$ mount /dev/sda2 /mnt/boot
cr0x@server:~$ mount /dev/sda1 /mnt/boot/efi
cr0x@server:~$ mount --bind /dev  /mnt/dev
cr0x@server:~$ mount --bind /proc /mnt/proc
cr0x@server:~$ mount --bind /sys  /mnt/sys
cr0x@server:~$ mount --bind /run  /mnt/run
cr0x@server:~$ chroot /mnt /bin/bash

Значення: Тепер ви працюєте, ніби завантажені в інстальовану ОС, з доступом до пристроїв і proc/sys.

Рішення: Якщо ви збираєтесь перебудувати initramfs, оновити GRUB або робити відновлення пакетів — робіть це з коректного chroot. Інакше ризикуєте створити артефакти завантаження для невірного середовища.

Завдання 12: Перевірте, чи root заблокований або прострочений

cr0x@server:~$ passwd -S root
root L 2025-10-01 0 99999 7 -1

Значення: Позначка L вказує на блокування. Інші стани включають P для встановленого пароля.

Рішення: Якщо root заблокований, але він потрібен тимчасово — розблокуйте і встановіть пароль, потім вирішіть, чи повертати блокування і покладатися на sudo.

Завдання 13: Безпечно встановіть або скиньте пароль root

cr0x@server:~$ passwd root
New password:
Retype new password:
passwd: password updated successfully

Значення: Аутентифікація root тепер має працювати (якщо PAM не зламаний).

Рішення: Використайте тимчасовий сильний пароль, збережіть його в інцидент‑сейфі, і поміняйте після інциденту. Не залишайте «тимчасовий» пароль у продакшені місяцями — час перетворює тимчасове на постійне.

Завдання 14: Перевірте sudoers (не редагуйте наосліп)

cr0x@server:~$ visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/ops: parsed OK

Значення: Синтаксис валідний. Якщо ні — інструмент вкаже, де проблема.

Рішення: Якщо sudoers зламаний, виправте вказаний файл. Якщо ви не можете використовувати visudo через проблеми з редактором в rescue, явно встановіть EDITOR=vi, а не редагуйте випадковими інструментами.

Завдання 15: Швидко перевірте PAM на предмет відсутніх модулів

cr0x@server:~$ grep -R --line-number -E "pam_unix|pam_sss|pam_tally2|pam_faillock" /etc/pam.d | head
/etc/pam.d/common-auth:25:auth    [success=1 default=ignore]      pam_unix.so nullok
/etc/pam.d/sshd:1:@include common-auth

cr0x@server:~$ ldconfig -p | grep pam_unix || true

Значення: Якщо PAM‑конфіг посилається на модулі, яких немає на диску, логіни відмовляють. Відсутність очікуваних PAM‑бібліотек — червоний прапор після часткових оновлень або надмірного очищення.

Рішення: Перевстановіть відповідні пакети з chroot, якщо є мережа/репозиторії; інакше використайте локальні носії або виправте стан пакетів при наступному завантаженні.

Завдання 16: Підтвердьте власність і права /etc/shadow

cr0x@server:~$ ls -l /etc/passwd /etc/shadow /etc/group /etc/gshadow
-rw-r--r-- 1 root root   2934 Dec 29 23:01 /etc/passwd
-rw-r----- 1 root shadow 1682 Dec 29 23:01 /etc/shadow
-rw-r--r-- 1 root root   1203 Dec 29 23:01 /etc/group
-rw-r----- 1 root shadow  986 Dec 29 23:01 /etc/gshadow

Значення: Якщо /etc/shadow доступний для читання всім — це інцидент безпеки; якщо він недоступний навіть для root (таке трапляється через дивні ACL), автентифікація ламається.

Рішення: Виправте власність і режим, якщо вони неправильні. Якщо права «виглядають» правильно, але автентифікація все одно не працює — перевірте ACL або атрибути immutable файлової системи.

Завдання 17: Перевірте immutable‑біти і ACL

cr0x@server:~$ lsattr /etc/shadow
---------------------- /etc/shadow
cr0x@server:~$ getfacl -p /etc/shadow | head
# file: /etc/shadow
# owner: root
# group: shadow
user::rw-
group::r--
other::---

Значення: Іммутабельний біт (i) або дивна ACL можуть завадити редагуванню або змінити семантику доступу.

Рішення: Якщо встановлений immutable і ви не знаєте чому — зупиніться. Часто це політичне рішення/засіб контролю. Знімайте його лише якщо розумієте потенційний радіус ураження.

Завдання 18: Якщо проблема з SSH — перевірте конфіг sshd офлайн

cr0x@server:~$ sshd -t -f /etc/ssh/sshd_config
cr0x@server:~$ grep -E "^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)" /etc/ssh/sshd_config
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes

Значення: sshd -t виходить без повідомлень, якщо конфіг OK; інакше виводить помилки. Root‑вхід може бути відключений політикою — це не «злом».

Рішення: Якщо вам потрібен аварійний віддалений доступ — краще відновити ключовий доступ відомого адміністратора, ніж увімкнути логін root по паролю. Якщо ви мусите змінити — робіть це тимчасово і логгируйте.

Завдання 19: Перебудуйте initramfs, коли розблокування дисків/LVM не працює

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

Значення: Генеруються образи initramfs для встановлених ядер.

Рішення: Робіть це коли завантаження падає через відсутні драйвери/модулі, зламані crypttab‑хуки або після відновлення пакетів LVM/crypt. Якщо ви нічого релевантного не міняли — не переставляйте артефакти завантаження «просто так».

Завдання 20: Переінсталюйте або оновіть GRUB тільки з доказами

cr0x@server:~$ grub-install /dev/sda
Installing for x86_64-efi platform.
Installation finished. No error reported.
cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0-amd64
Found initrd image: /boot/initrd.img-6.12.0-amd64
done

Значення: GRUB встановлений і конфіг згенеровано, виявлено ядра/initrds.

Рішення: Робіть це лише якщо були симптоми з bootloader (відсутній GRUB, неправильний пункт завантаження, після заміни диска). Перевстановлення GRUB щоб «виправити пароль root» — як міняти шини, щоб почути радіо.

Завдання 21: Вихід з chroot чисто і відмонтування у зворотному порядку

cr0x@server:~$ exit
cr0x@server:~$ umount -R /mnt/run
cr0x@server:~$ umount -R /mnt/dev
cr0x@server:~$ umount -R /mnt/proc
cr0x@server:~$ umount -R /mnt/sys
cr0x@server:~$ umount -R /mnt/boot/efi
cr0x@server:~$ umount -R /mnt/boot
cr0x@server:~$ umount -R /mnt/var
cr0x@server:~$ umount -R /mnt

Значення: Відсутність «target is busy» означає, що монтування чисто звільнено.

Рішення: Якщо unmount скаржиться — знайдіть, що тримає ( lsof або fuser ) перед перезавантаженням. Грубі відмонтування після ремонту файлової системи — шлях від «пофіксовано» до «зламано».

Жарт №2: Хороша новина у rescue mode — ви можете виправити що завгодно. Погана новина — ви також можете виправити що завгодно.

Три корпоративні міні‑історії (що реально трапляється)

Інцидент 1: Неправильне припущення (це було «просто скидання пароля»)

Команда успадкувала флот Debian від вендора. Один хост перестав приймати SSH для інженера on‑call. Інженер припустив, що root‑пароль неправильний,
завантажився в rescue ISO, змонтував те, що виглядало як root‑том, і скинув root.

Сервер все одно не завантажувався. Логіни не проходили. Рівень фрустрації зростав, зміни множились. Хтось помітив, що у хоста були два диски:
малий диск ОС і великий диск для даних, обидва ext4, обидва змонтовані. Rescue‑робочий процес змонтував диск даних у /mnt і скинув пароль root
у сторонньому chroot, який навіть не належав ОС.

Справжня проблема була в застарілому записі в /etc/fstab, що посилалася на виведений з експлуатації iSCSI LUN. systemd чекав, потім опускався в emergency mode.
Root‑доступ ніколи не був блокером; система просто не досягала корисного таргету.

Вони відновилися, відновивши правильні монтування, додавши nofail та короткий таймаут пристрою для некритичних томів, і перезавантажилися.
Потім вони правильно провели ротацію облікових даних — бо фактично змінили пароль на неправильній файловій системі і створили проблему з комплаєнсом.

Урок не в «будь обережним». Це дешеві поради. Урок — запровадити процедуру: завжди ідентифікуйте root через findmnt/lsblk і підтверджуйте,
що /mnt/etc/os-release відповідає очікуваній інсталяції перед будь‑якою зміною облікових даних.

Інцидент 2: Оптимізація, яка обернулась проти (жорсткіші правила автентифікації зупинили сайт)

Інша команда вирішила стандартизувати безпеку логінів. Вони запушили зміни в PAM, щоб примусити суворіші паролі й блокування.
Це виглядало розумно в код‑рев’ю: кілька рядків у /etc/pam.d/common-auth.

Підмножина серверів відразу після рутинного оновлення і перезавантаження перестала приймати логіни. Консоль показувала, що правильні паролі відхиляються.
Root не «заблокований»; автентифікація стала неможливою, бо посилання на модуль PAM відсутнє на тих хостах.

Чому лише підмножина? Частина серверів була побудована з мінімального образу, де опціональні PAM‑модулі не були встановлені.
Оптимізація «зменшити пакети» спрацювала, поки хтось не припустив, що стек автентифікації однаковий скрізь.

Відновлення пройшло через rescue mode і chroot з перевстановленням відсутніх пакетів і відкатом PAM‑конфігу до відомого робочого базису.
Після інциденту вони розбили зміни PAM на дві фази: спочатку доставити пакети, перевірити наявність модулів, а вже потім активувати конфіг. Нудно. Правильно.

Інцидент 3: Нудна, але правильна практика, що врятувала день (нотатки і read‑only монтування)

Виробничий вузол бази даних перестав завантажуватись після оновлення ядра. Він опинився в emergency mode з мінімальним виводом на віддаленій консолі.
On‑call зробив героїчну, але просту річ: нічого не робив. Вони не почали редагувати; вони почали документувати.

Вони змонтували root у режимі read‑only, витягли останні помилки завантаження з журналу і виявили, що система не може розблокувати зашифрований том.
Образ initramfs був згенерований без потрібної інтеграції cryptsetup після часткового оновлення.

Оскільки вони змонтували read‑only спочатку, вони уникли записів журналу і replay‑записів на стеку зберігання, який вже був під підозрою.
Потім вони перемонтували read‑write тільки щоб перебудувати initramfs і оновити конфіг GRUB, використавши чистий chroot з bind‑монтами.

Машина завантажилась чисто. Пост‑мортем пройшов майже безболісно, бо on‑call мав таймлайн і перелік виконаних команд.
Жодних містичних історій. Просто виправлення, що відповідало доказам.

Поширені помилки: симптом → корінна причина → виправлення

1) Симптом: «пароль root правильний, але логін в усіх місцях відмовляє»

Корінна причина: Неправильна конфігурація PAM або відсутній PAM‑модуль (після оновлень, очищення або ручних правок).

Виправлення: У chroot перевірте файли PAM у /etc/pam.d. Перевстановіть відсутні пакети автентифікації, відкотіть до базового конфігу і протестуйте з локальної консолі після перезавантаження.

2) Симптом: Опущено в emergency mode, просять root‑пароль для обслуговування

Корінна причина: Несправне монтування у /etc/fstab (помилковий UUID, відсутній диск, повільне мережеве сховище) блокувало local-fs.target.

Виправлення: Змонтуйте root і перегляньте /etc/fstab. Виправте UUID за допомогою blkid, або позначте некритичні монтування як nofail з невеликим таймаутом.

3) Симптом: sudo каже «no valid sudoers sources found» або «parse error»

Корінна причина: Синтаксична помилка або неправильні права/власність у /etc/sudoers або /etc/sudoers.d/*.

Виправлення: Використайте visudo -c в chroot. Виправте файл, що спричиняє проблему, і встановіть правильні права (зазвичай 0440) і власність root.

4) Симптом: SSH відмовляє після «швидкого жорсткішання»

Корінна причина: Невалідний sshd_config, відсутні ключі хоста або неправильні права файлів у ~/.ssh.

Виправлення: Перевірте конфіг з sshd -t. Підтвердьте наявність ключів у /etc/ssh. Перевірте права й власність authorized_keys.

5) Симптом: Після скидання пароля в rescue система все одно відмовляє в root‑логіні

Корінна причина: Ви скинули пароль на неправильній змонтованій файловій системі, або root налаштований забороняти вхід по паролю (політика), або PAM блокує це.

Виправлення: Підтвердьте, що змонтували правильний root (перевірте /etc/os-release, hostname і UUID дисків). Підтвердьте політику в PAM/sshd і відрегулюйте в правильному шарі.

6) Симптом: «Authentication token manipulation error» при виконанні passwd

Корінна причина: Root FS змонтовано read‑only, або права/власність /etc/shadow зламані, або файловій системі не вистачає місця/інодів.

Виправлення: Перемонтуйте в read‑write цілеспрямовано, виправте режим/власність /etc/shadow, перевірте вільне місце з df -h і df -i.

7) Симптом: Система завантажується, але сервіси падають і sudo зависає

Корінна причина: Зламаний DNS або NSS конфіг (наприклад, вказано мертвий LDAP/SSSD), що викликає зависання запитів; sudo часто викликає розвʼязку користувач/група.

Виправлення: У rescue/chroot перевірте /etc/nsswitch.conf, конфіг SSSD і забезпечте роботу локальної аутентифікації. Розгляньте тимчасове відключення віддалених залежностей автентифікації, щоб відновити контроль.

8) Симптом: Петля завантаження після оновлення ядра, не доходите до запиту логіну

Корінна причина: initramfs без драйверів сховища, зламаний crypttab або несумісні модулі ядра.

Виправлення: Завантажте старе ядро з GRUB, якщо доступне. У rescue, chroot і запустіть update-initramfs -u -k all, потім update-grub.

Чеклісти / покрокові плани

План A: Потрібен лише root (без проблем з завантаженням/сховищем)

1. Завантажте rescue target з GRUB або інсталятор‑rescue.
2. Запустіть lsblk і ідентифікуйте правильний root‑том.
3. Змонтуйте root read‑only у /mnt. Підтвердіть, що /mnt/etc/os-release відповідає очікуваному хосту.
4. Змонтуйте /boot, /boot/efi і /var, якщо окремі.
5. Bind‑монтуйте /dev, /proc, /sys, /run, потім зробіть chroot.
6. Перевірте стан root: passwd -S root і chage -l root.
7. Встановіть тимчасовий сильний пароль root: passwd root.
8. Перевірте sudoers: visudo -c. Виправте за потреби.
9. Вийдіть з chroot, відмонтуйте чисто, перезавантажтеся.
10. Після входу поверніть облікові дані у належний стан і задокументуйте зміни.

План B: Система впадає в emergency mode (fstab/блокери монтажу)

1. Не скидайте паролі ще. Розглядайте це як інцидент залежностей завантаження.
2. Змонтуйте root read‑only і перегляньте журнал останнього завантаження.
3. Огляньте /etc/fstab на предмет застарілих UUID, недоступних мережевих монтувань або відсутніх дисків.
4. Використайте blkid щоб підтвердити ідентифікатори і виправити їх.
5. Для некритичних монтувань додайте nofail і x-systemd.device-timeout=10s, щоби не блокувати завантаження.
6. Перемонтуйте root read‑write лише для мінімальної зміни.
7. Перезавантажтеся і перевірте, чи система досягає multi‑user таргету.

План C: Не піднімається зашифрований root / LVM

1. У rescue підтвердьте, що зашифрований пристрій видимий (lsblk і dmesg).
2. Розблокуйте з cryptsetup luksOpen; перевірте статус.
3. Активуйте LVM: vgscan, vgchange -ay.
4. Змонтуйте root і зробіть chroot правильно.
5. Перевірте /etc/crypttab, хуки initramfs і перебудуйте initramfs.
6. Оновіть конфіг GRUB при потребі, потім перезавантажтеся.

План D: SSH зламаний, але локальний доступ є

1. Перевірте конфіг SSH з sshd -t (з chroot якщо потрібно).
2. Підтвердьте наявність ключів хоста і правильні права в /etc/ssh.
3. Надайте пріоритет відновленню ключового доступу відомого адміністратора перед увімкненням входу root по паролю.
4. Тільки після стабілізації доступу розгляньте політики та жорсткість налаштувань.

FAQ

1) Коли використовувати rescue.target або emergency.target?

Використовуйте rescue.target, коли хочете мінімальну систему, але з більшістю звичних сервісів і монтажів.
Використовуйте emergency.target, коли монтажі зламані або підозрюєте fstab; він зменшує залежності і дає оболонку швидше.

2) Чи безпечно скидати пароль root у rescue mode?

Безпечно лише після того, як ви довели, що змонтували правильну кореневу файлову систему і що вона здорова.
Це операційно ризиковано, бо змінює безпековий стан. Використайте тимчасовий пароль, зафіксуйте його в інцидент‑сховищі, поміняйте його пізніше і розгляньте повторне блокування root, якщо це політика.

3) Чому passwd дає «Authentication token manipulation error»?

Найчастіше: файлову систему змонтовано read‑only, диск заповнений, або права/власність /etc/shadow неправильні.
У rescue часто забувають, що змонтували / як ro. Ця помилка каже, що база облікових даних не може бути записана.

4) Чи можна просто редагувати /etc/shadow вручну?

Можна, але не варто, якщо ви не впевнені, що робите. Використовуйте passwd, щоб коректно обробити хешування і блокування файлу.
Якщо мусите редагувати, забезпечте правильні права і формат — один зламаний рядок може зламати логіни для всіх.

5) Я виправив sudoers, але sudo все одно відмовляє після перезавантаження. Чому?

Перевірте затримки при розвʼязуванні імен (NSS/SSSD/LDAP) і пошук груп. sudo звертається до списку користувачів/груп і може зависнути, якщо віддалені провайдери ідентичності недоступні.
Якщо потрібно — тимчасово забезпечте роботу локальної аутентифікації через /etc/passwd//etc/group.

6) Коли запускати fsck або xfs_repair?

Запускайте їх, коли є докази: помилки монтування, I/O помилки або повідомлення журналу про корупцію.
Для ext‑файлових систем fsck — стандарт. Для XFS використовуйте xfs_repair (часто вимагає відмонтування). Не запускайте ремонт на змонтованій ФС, якщо інструмент цього не підтримує.

7) Я на віддаленій віртуальній машині без консолі для введення пароля LUKS. Що робити?

Це обмеження дизайну, а не трюк rescue. Потрібен спосіб передати фразу віддалено (віртуальна консоль), використати keyfile з безпечним отриманням під час завантаження,
або переробити workflow розблокування при завантаженні. Rescue mode допоможе діагностувати, але не створить віддалений клавіатурний ввід.

8) Чи варто перевстановлювати GRUB під час відновлення root?

Ні, якщо немає симптомів завантажувача. Перевстановлення GRUB invasive і може порушити складні налаштування завантаження.
Якщо система доходить до запиту логіну — завантажувач, ймовірно, не є причиною відсутності root‑доступу.

9) Як підтвердити, що змонтував правильний root перед змінами?

Перевірте /mnt/etc/os-release, /mnt/etc/hostname і порівняйте UUID дисків з інвентарем.
Також підтвердіть наявність очікуваних артефактів завантаження (/mnt/boot) і що findmnt -R /mnt відповідає відомій схемі розділів.

10) Чи можна відновитися, додавши init=/bin/bash при завантаженні?

Іноді так, але це грубий підхід і обходить нормальну ініціалізацію. Він також може створити плутані стани з зашифрованими дисками і очікуваннями systemd.
Віддавайте перевагу systemd.unit=emergency.target або rescue інсталятору, а потім робіть чисте chroot‑ремонтування.

Наступні кроки після повернення доступу

Повернення root — це не фініш; це повернення можливості робити свідомі зміни. Зробіть три речі перед тим, як оголосити перемогу:

1. Стабілізуйте доступ: Забезпечте щонайменше два незалежні адміністративні шляхи (консоль + SSH з ключами для адміністратора). Уникайте залежності від одного пароля.
2. Виправте реальну корінну причину: Якщо тригером були fstab, PAM, initramfs або залежність від провайдера ідентичності, усуньте це зміною, яку можна обґрунтувати доказами.
3. Залиште сліди: Запишіть, що ви змінили, чому і як відкотити. Покладіть це туди, де ваша команда справді знайде під час наступного інциденту.

Найкращий сейв — той, що вам знадобиться лише один раз. Після інциденту інвестуйте в передбачувану розмітку дисків, протестовані процедури оновлення і політику для root/sudo, яка задокументована, примусова і нудна.
Нудьга — це добре. Нудні завантаження — теж.