Debian 13 : récupérer l’accès root en mode rescue — faites-le sans empirer la situation

Les seules règles qui comptent en mode rescue

Le mode rescue est un scalpel, pas une tronçonneuse. L’objectif est restreint : retrouver un accès administratif contrôlé, puis sortir proprement.
Ne “réparez pas tout pendant que vous êtes là”. C’est comme ça que des incidents d’accès root deviennent des reconstructions de plusieurs jours.

Règle 1 : Prouvez quel système vous touchez

Les environnements de rescue sont remplis de pièges parce qu’ils facilitent le montage de disques provenant de plusieurs systèmes.
Avant de modifier quoi que ce soit, confirmez le nom d’hôte, les identifiants des disques et le système de fichiers root que vous comptez réparer.
Si vous ne pouvez pas le prouver, vous devinez. Deviner coûte cher.

Règle 2 : Montez en lecture seule par défaut jusqu’à ce que vous ayez identifié la faute

Beaucoup d’échecs d’“accès root” ne sont pas des problèmes d’authentification. Ce sont des échecs de montage au démarrage, un initramfs cassé, des modules PAM corrompus,
des permissions mal appliquées sur /etc/shadow, ou une invite de chiffrement expirée que vous ne voyez pas sur des démarrages headless.

Montez en lecture seule d’abord. Rassemblez des preuves. Ensuite, remontez en lecture-écriture pour la seule modification qui adresse la cause racine.

Règle 3 : Préférez des changements minimaux et réversibles

Éditer la pile PAM, sudoers ou la configuration d’SSHD en mode panique est la façon dont vous vous verrouillez deux fois.
Si vous devez changer l’authentification, suivez un chemin testé : définissez un mot de passe root temporaire, réactivez un utilisateur admin connu, et planifiez une correction complète.

Règle 4 : Conservez une trace médico-légale

Vous oublierez ce que vous avez fait. Votre coéquipier demandera. Votre futur vous vous en voudra.
Prenez des notes : ce qui était cassé, ce que vous avez exécuté, quel fichier vous avez modifié. Même un journal texte rudimentaire dans /root/rescue-notes.txt vaut de l’or.

Blague #1 : Le mode rescue, c’est comme la chirurgie — champ stérile, instruments propres, et absolument pas de “voyons ce qui se passe si je touche ceci”.

Faits et contexte intéressants (pourquoi Debian se comporte ainsi)

• Roots en mode mono-utilisateur : Le “single-user mode” Unix traditionnel précède systemd de décennies et visait la récupération sur console locale quand les services multi-utilisateurs étaient cassés.
• systemd emergency vs rescue : Sur les systèmes systemd, les targets “rescue” visent un système minimal ; “emergency” est encore plus réduit — souvent une shell de type initramfs avec moins de montages.
• Le compte root peut être verrouillé par conception : Beaucoup d’installations Debian s’appuient sur sudo et peuvent verrouiller root en plaçant un hachage spécial. Ce n’est pas un bug ; c’est un choix de politique.
• PAM est une pile, pas un interrupteur : Pluggable Authentication Modules permet aux organismes d’échanger les méthodes d’auth sans réécrire les applications, ce qui signifie aussi qu’une ligne cassée peut tout casser.
• /etc/shadow n’a pas toujours été séparé : La séparation entre /etc/passwd et /etc/shadow est une évolution de sécurité pour cacher les hachages aux utilisateurs non-root.
• Initramfs est un petit OS : Le Linux moderne démarre via un initial RAM filesystem qui charge des pilotes, décrypte des disques, active LVM, et monte le vrai root. Si ce petit OS est faux, votre “problème root” est en amont.
• GRUB est devenu le choix par défaut pour de bonnes raisons : La capacité de GRUB à éditer les paramètres du noyau au démarrage sauve des vies en recovery — et c’est aussi pourquoi l’accès console physique compte.
• Les options de montage peuvent vous verrouiller dehors : Une seule ligne erronée dans /etc/fstab peut vous envoyer en emergency mode, même si vos mots de passe sont corrects.

Une citation à garder en tête quand la pression monte : “L’espoir n’est pas une stratégie.” — General Gordon R. Sullivan.

Guide de diagnostic rapide (vérifiez 1/2/3)

Lorsque vous êtes sur une console avec un système cassé, la route la plus rapide est de classifier la panne. Pas par impressions. Par signaux.

Vérification 1 : S’agit-il d’un échec d’authentification ou d’un échec de démarrage/montage ?

• Si vous obtenez une invite de connexion mais que root/sudo échoue : probablement état du compte, PAM, permissions de shadow, ou sudoers.
• Si vous n’atteignez jamais une connexion normale et que vous êtes en emergency mode : probablement fstab, initramfs, activation LUKS/LVM, erreurs de système de fichiers.
• Si le système est en service mais vous ne pouvez pas y accéder à distance : probablement réseau, configuration sshd, clés d’hôte, pare-feu, ou permissions de clé.

Vérification 2 : Le système de fichiers root est-il intact et montable ?

Avant de toucher à l’auth, vérifiez que vous pouvez monter le vrai root. Si vous ne pouvez pas monter root en toute sécurité, arrêtez et diagnostiquez le stockage.
Modifier les mots de passe sur le mauvais point de montage est un classique qui vous coûte cher.

Vérification 3 : Pouvez-vous reproduire la panne via les logs ?

En mode rescue, montez root en lecture seule et inspectez /var/log et le journal. Si la panne est répétable et consignées, vous pouvez la corriger précisément.
Si elle n’est pas journalisée, vous pouvez souvent inférer la cause à partir d’un dérive de configuration et d’erreurs au démarrage.

Façons d’entrer en mode rescue sur Debian 13

1) GRUB : éditer la ligne de commande du noyau (accès console)

Si vous atteignez GRUB, vous pouvez généralement accéder à la récupération root. Sélectionnez votre entrée de démarrage normale, appuyez sur e, et ajoutez :
systemd.unit=rescue.target ou systemd.unit=emergency.target à la ligne Linux.

Le target rescue tend à monter plus de choses (y compris certains montages). Emergency target est minimal et utile quand les montages sont cassés.

2) Média d’installation Debian : “Rescue a broken system”

Démarrez l’ISO d’installation (ou netinst) et choisissez l’option rescue. Il peut détecter les systèmes installés, les monter, et proposer un chroot.
C’est souvent la voie la plus propre sur des serveurs headless où vous avez KVM distant ou une console virtuelle.

3) Cloud/VM : attacher un ISO rescue ou utiliser l’image rescue du fournisseur

En production, vous n’avez peut-être pas d’accès physique. Utilisez la console de votre hyperviseur et démarrez un ISO de rescue, ou le mode rescue du fournisseur.
La même discipline s’applique : identifiez les disques par des IDs stables, montez en lecture seule d’abord, et soyez prudent avec les volumes chiffrés.

Carte de triage : ce que vous réparez réellement

“Récupérer l’accès root” peut vouloir dire plusieurs problèmes différents. Classez avant d’agir.

A. Compte root verrouillé ou mot de passe inconnu

Root peut être verrouillé volontairement, ou vous avez hérité d’un système où personne ne connaît le mot de passe.
La correction est généralement : monter le système, chrooter, définir un nouveau mot de passe ou réactiver sudo pour un utilisateur admin connu.

B. sudo cassé (syntaxe, permissions, mauvais fichier)

Une entrée sudoers malformée peut casser tout l’usage de sudo. Cela ressemble à “pas d’accès root”, mais c’est en fait une erreur de validation de configuration.
La correction : valider avec visudo (ou réparer soigneusement) depuis un chroot.

C. Pile PAM/stack d’auth cassée

Si des modules PAM ont été supprimés, sont incompatibles ou mal configurés, les connexions échoueront même avec les bons mots de passe.
La correction consiste généralement à restaurer les paquets/configurations corrects ; évitez les bricolages “désactiver PAM”.

D. Le système tombe en emergency mode (fstab, fsck, périphérique introuvable)

Ce n’est pas un problème d’auth. C’est un problème de dépendance au démarrage. Réparez le montage, l’UUID, ou le problème de système de fichiers d’abord.

E. Root chiffré ou LVM non activé

Si initramfs ne peut pas déverrouiller LUKS ou assembler LVM, votre root n’apparaît jamais. La correction se situe dans initramfs, crypttab, métadonnées LVM, ou pilotes manquants.

F. Accès distant perdu (sshd, clés, pare-feu) mais root local existe

Parfois la machine est correcte et seul l’accès distant est cassé. Ne réinitialisez pas root simplement parce que SSH est en panne.
Réparez SSH et le réseau avec des changements minimaux.

Tâches pratiques (commandes, sorties, décisions)

Voici les tâches que j’exécute réellement en scénario de rescue. Chacune contient : commande, ce que signifie une sortie typique, et la décision à prendre.
Les commandes supposent une shell de rescue avec privilèges root. L’invite hôte est figée selon vos besoins.

Tâche 1 : Identifier les disques et partitions (ne devinez pas)

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

Signification : Vous pouvez voir si vous avez des partitions simples, LUKS, LVM, et quels types de FS nécessitent des outils (ext4, xfs, btrfs).

Décision : Si vous voyez des couches LUKS/LVM, planifiez de déverrouiller et d’activer avant le montage. Si le FS root n’est pas évident, arrêtez et cartographiez-le avant de modifier quoi que ce soit.

Tâche 2 : Confirmer que le noyau a vu le stockage attendu

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

Signification : L’absence d’erreurs I/O est bonne. Si vous voyez des timeouts ou erreurs de lecture, vous êtes peut-être en territoire de disque défaillant, pas d’auth.

Décision : Si le stockage est instable, minimisez les écritures. Préférez les montages lecture seule, prenez une image/snapshot si possible, et planifiez un remplacement plutôt que “corriger les configs”.

Tâche 3 : Si LUKS est utilisé, déverrouillez explicitement (et vérifiez)

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

Signification : Le device mapper existe et est actif. Le mode indique s’il est inscriptible à ce niveau.

Décision : Si le déverrouillage échoue, ne forcez pas. Vérifiez que vous êtes sur le bon device, contrôlez la disposition du clavier dans l’environnement de rescue, et confirmez la source de la passphrase.

Tâche 4 : Activer les volumes LVM (si présents)

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

Signification : Les métadonnées LVM sont lisibles et les volumes logiques sont actifs.

Décision : Si l’activation échoue, inspectez pvs/vgs/lvs et considérez si le PV est manquant (disque détaché) ou filtré par la config LVM.

Tâche 5 : Montez root en lecture seule d’abord (toujours)

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

Signification : Le système de fichiers root se monte proprement en mode lecture seule.

Décision : Si le montage échoue avec “wrong fs type” ou “bad superblock”, arrêtez et lancez des vérifications de système de fichiers avec la bonne chaîne d’outils (tâches suivantes). Ne commencez pas à éditer /etc si le FS est malade.

Tâche 6 : Montez les systèmes de fichiers d’appui (boot, EFI, var) correctement

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

Signification : Votre chroot (plus tard) verra la même disposition que le système en place attend.

Décision : Si /var est séparé et non monté, les journaux et l’état d’auth peuvent sembler “manquants”, menant à de mauvaises conclusions.

Tâche 7 : Vérifiez ce qui a réellement échoué au dernier démarrage (journal)

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'.

Signification : Il s’agit d’un schéma d’échec au démarrage (montage fstab), pas d’un échec de mot de passe.

Décision : Réparez la définition du montage avant de toucher aux comptes utilisateurs. Sinon vous “récupérerez root” et retomberez en emergency mode.

Tâche 8 : Inspecter et valider /etc/fstab en toute sécurité

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

Signification : Ce UUID=deadbeef... est suspect s’il n’existe pas.

Décision : Comparez avec blkid. Si l’UUID est obsolète, corrigez-le ou ajoutez nofail,x-systemd.device-timeout=10s pour les montages non critiques afin de laisser le système démarrer.

Tâche 9 : Vérifiez les UUID et labels (vérité terrain)

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"

Signification : Si un UUID dans fstab n’apparaît pas dans cette liste, il ne sera pas monté au démarrage.

Décision : Corrigez l’identifiant incorrect. Si le disque est volontairement retiré (volume déclassé), retirez/commentez le montage ou marquez-le nofail.

Tâche 10 : Si l’intégrité du FS est douteuse, vérifiez-la correctement

Pour ext4, utilisez fsck sur un système de fichiers démonté. Pour XFS, on utilise généralement xfs_repair (et il est pointilleux sur le fait d’être démonté).

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

Signification : “clean” signifie que le FS n’est probablement pas votre problème.

Décision : S’il rapporte des erreurs et les corrige, remontez et revérifiez les journaux. S’il signale une corruption sévère, faites une image/sauvegarde avant d’écrire davantage.

Tâche 11 : Préparer un chroot correctement (montages 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

Signification : Vous opérez maintenant comme si vous aviez démarré dans l’OS installé, avec les nœuds device et proc/sys disponibles.

Décision : Si vous allez reconstruire initramfs, mettre à jour GRUB, ou réparer des paquets, faites-le depuis un chroot correct. Sinon vous risquez de générer des artefacts de démarrage pour le mauvais environnement.

Tâche 12 : Vérifiez si root est verrouillé ou expiré

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

Signification : Le L indique verrouillé. Les autres états incluent P pour mot de passe défini.

Décision : Si root est verrouillé mais que vous en avez besoin temporairement, déverrouillez et définissez un mot de passe, puis décidez plus tard si vous reverrouillez et comptez sur sudo.

Tâche 13 : Définir ou réinitialiser le mot de passe root en toute sécurité

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

Signification : L’authentification root devrait maintenant fonctionner (tant que PAM n’est pas cassé).

Décision : Utilisez un mot de passe temporaire fort, placez-le dans votre coffre d’incident, et faites-le tourner après l’incident. Ne laissez pas un “temporaire” en production pendant des mois — le temps transforme le temporaire en permanent.

Tâche 14 : Valider sudoers (ne pas éditer aveuglément)

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

Signification : La syntaxe est valide. S’il échoue, il vous dira où.

Décision : Si sudoers est cassé, corrigez le fichier indiqué. Si vous ne pouvez pas utiliser visudo à cause d’un éditeur absent en rescue, définissez EDITOR=vi explicitement plutôt que d’éditer avec des outils aléatoires.

Tâche 15 : Vérifier rapidement une rupture PAM (modules manquants fréquents)

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

Signification : Si la config PAM référence des modules absents sur le disque, les connexions échouent. L’absence des bibliothèques PAM attendues est un signal d’alerte après des mises à jour partielles ou un nettoyage trop zélé.

Décision : Réinstallez les paquets pertinents depuis le chroot si l’accès au réseau/répertoire est disponible ; sinon utilisez un média local ou corrigez l’état des paquets au démarrage.

Tâche 16 : Confirmer la propriété et les permissions de /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

Signification : Si /etc/shadow est lisible par tous, c’est un incident de sécurité ; s’il n’est pas lisible par root (oui, ça arrive via ACL étranges), l’auth échoue.

Décision : Corrigez la propriété et le mode si c’est incorrect. Si les permissions “semblent” correctes mais que l’auth échoue, vérifiez les ACL au niveau FS ou les attributs immuables.

Tâche 17 : Vérifier les flags immuables et surprises 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::---

Signification : Un bit immuable (i) ou une ACL étrange peut empêcher les éditions ou modifier la sémantique d’accès.

Décision : Si l’immuable est défini et que vous ne savez pas pourquoi, arrêtez. C’est souvent un outil de politique. Ne l’enlevez que si vous comprenez le rayon d’impact.

Tâche 18 : Si SSH est le problème, validez la config sshd hors ligne

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

Signification : sshd -t sort silencieusement si la config est OK ; il affiche les erreurs sinon. Le login root peut être désactivé par politique ; ce n’est pas “cassé”.

Décision : Si vous avez besoin d’un accès distant d’urgence, préférez activer un utilisateur admin connu avec des clés plutôt que d’activer le login root par mot de passe. Si vous devez basculer, faites-le temporairement et consignez-le.

Tâche 19 : Rebuild initramfs quand le déverrouillage disque / activation LVM échoue

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

Signification : Les images initramfs sont régénérées pour les noyaux installés.

Décision : Faites cela quand le démarrage échoue à cause de pilotes/modules manquants, de hooks crypttab cassés, ou après avoir réparé des paquets LVM/crypt. Si vous n’avez rien changé de pertinent, ne bousculez pas les artéfacts de démarrage “juste parce que”.

Tâche 20 : Réinstaller ou rafraîchir GRUB seulement quand vous avez des preuves

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

Signification : GRUB est installé et la config est régénérée, détectant noyaux/initrds.

Décision : Ne faites cela que si vous avez un symptôme de bootloader (GRUB manquant, mauvaise entrée de démarrage, après remplacement de disque). Réinstaller GRUB pour “réparer le mot de passe root” revient à changer les pneus pour réparer la radio.

Tâche 21 : Quitter le chroot proprement et démonter dans l’ordre inverse

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

Signification : L’absence de “target is busy” signifie que vos montages sont proprement libérés.

Décision : Si le démontage se plaint, trouvez ce qui le retient (lsof ou fuser) avant de redémarrer. Des démontages sales après une réparation de FS sont la façon de transformer “je l’ai réparé” en “je l’ai cassé”.

Blague #2 : La bonne nouvelle au sujet du mode rescue est que vous pouvez tout réparer. La mauvaise nouvelle est que vous pouvez aussi tout ‘‘réparer’’.

Trois mini-histoires en entreprise (ce qui arrive vraiment)

Incident 1 : La mauvaise hypothèse (c’était “juste un reset de mot de passe”)

Une équipe a hérité d’un parc Debian d’un fournisseur. Un hôte a cessé d’accepter SSH pour l’ingénieur d’astreinte. L’ingénieur a supposé que le mot de passe root était incorrect,
a démarré sur un ISO de rescue, monté ce qui semblait être le volume root, et réinitialisé root.

Le serveur ne démarrera toujours pas. Il n’acceptait toujours pas les connexions. La frustration a augmenté, les changements se sont multipliés. Quelqu’un a alors remarqué que l’hôte avait deux disques :
un petit disque OS et un grand disque de données, tous deux ext4, tous deux montables. Le workflow de rescue avait monté le disque de données sur /mnt et réinitialisé un mot de passe root
dans un chroot errant qui n’était même pas l’OS.

Le vrai problème était une entrée /etc/fstab obsolète pointant vers un LUN iSCSI décommissionné. systemd attendait, puis tombait en emergency mode.
L’accès root n’était jamais le goulot d’étranglement ; le système n’atteignait pas une cible utilisable.

Ils ont récupéré en restaurant les montages corrects, ajoutant nofail et un court timeout d’appareil pour les volumes non critiques, puis en redémarrant.
Ensuite ils ont fait tourner les identifiants correctement — parce qu’ils avaient, en fait, changé un mot de passe sur le mauvais système de fichiers et créé un casse-tête de conformité.

La leçon n’était pas “soyez prudent”. C’est un conseil bon marché. La leçon fut d’imposer une procédure : toujours identifier le root via findmnt/lsblk et confirmer
que /mnt/etc/os-release correspond à l’installation attendue avant toute modification de crédential.

Incident 2 : L’optimisation qui a mal tourné (durcissement d’auth qui a mis tout le site à terre)

Un autre atelier a décidé de standardiser la sécurité des connexions. Ils ont poussé un changement à PAM pour appliquer une complexité de mot de passe et des verrous plus stricts.
Cela semblait raisonnable en revue de code : juste quelques lignes de module dans /etc/pam.d/common-auth.

Un sous-ensemble de serveurs a échoué aux connexions immédiatement après une mise à jour routinière et un redémarrage. Les accès console montraient que des mots de passe corrects étaient rejetés.
Root n’était pas “verrouillé” ; il était simplement impossible d’authentifier parce qu’un module PAM référencé n’existait pas sur ces hôtes.

Pourquoi le sous-ensemble ? Certains serveurs étaient construits depuis une image de base allégée où des modules PAM optionnels n’étaient pas installés.
L’optimisation visait à “réduire l’empreinte des paquets”, et elle a réussi jusqu’à ce que quelqu’un suppose que la pile d’auth était identique partout.

La récupération a utilisé le mode rescue et le chroot pour réinstaller les paquets manquants et revenir à une configuration PAM connue bonne.
Après l’incident, ils ont scindé les changements PAM en deux phases : livrer d’abord les paquets, valider la présence des modules, puis activer la config. Ennuyeux. Correct.

Incident 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation (notes et montages en lecture seule)

Un nœud de base de données en production a cessé de démarrer après une mise à jour du noyau. Il a atterri en emergency mode avec une sortie minimale sur la console distante.
Le premier d’astreinte a fait quelque chose d’héroïque : rien. Il n’a pas commencé à éditer ; il a commencé à documenter.

Il a monté le système de fichiers root en lecture seule, extrait les dernières erreurs de démarrage du journal, et a trouvé que le système ne déverrouillait pas un volume chiffré.
L’image initramfs avait été générée sans l’intégration correcte de cryptsetup après une mise à jour partielle.

Parce qu’ils ont monté en lecture seule d’abord, ils ont évité des écritures de journalisation et de replay sur une pile de stockage déjà suspecte.
Ils ont ensuite remonté en lecture-écriture seulement pour reconstruire initramfs et mettre à jour la configuration GRUB, en utilisant un chroot propre avec des montages bind.

La machine a redémarré proprement. Le post-mortem fut presque indolore parce que l’astreinte avait une timeline et une liste de commandes exécutées.
Pas de mystère. Pas de folklore. Juste une correction fondée sur des preuves.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : “le mot de passe root est correct mais la connexion échoue partout”

Cause racine : Mauvaise configuration PAM ou module PAM manquant (après des mises à jour, nettoyage, ou éditions manuelles).

Correction : Dans le chroot, validez les fichiers PAM sous /etc/pam.d. Réinstallez les paquets d’auth manquants, revenez à la config baseline, puis testez depuis la console locale après reboot.

2) Symptom : Tombé en emergency mode, on demande le mot de passe root pour maintenance

Cause racine : Un montage défaillant dans /etc/fstab (UUID erroné, disque manquant, stockage réseau lent) a bloqué local-fs.target.

Correction : Montez root en lecture seule et inspectez /etc/fstab. Corrigez les UUID avec blkid, ou marquez les montages non critiques nofail avec un court timeout.

3) Symptom : sudo indique “no valid sudoers sources found” ou “parse error”

Cause racine : Erreur de syntaxe ou permissions/possession incorrectes dans /etc/sudoers ou /etc/sudoers.d/*.

Correction : Utilisez visudo -c dans le chroot. Corrigez le fichier fautif et assurez les permissions correctes (généralement 0440) et la propriété root.

4) Symptom : SSH refusé après un “durcissement rapide”

Cause racine : sshd_config invalide, clés d’hôte manquantes, ou permissions des fichiers clés wrong sous ~/.ssh.

Correction : Validez la config avec sshd -t. Confirmez que les clés d’hôte existent dans /etc/ssh. Vérifiez permissions et propriété des authorized_keys.

5) Symptom : Après reset de mot de passe en rescue, le système refuse toujours root

Cause racine : Vous avez réinitialisé le mot de passe sur le mauvais système de fichiers monté, ou root est configuré pour interdire le login par mot de passe (politique), ou PAM le bloque.

Correction : Confirmez que vous avez monté le bon root (vérifiez /etc/os-release, hostname, et les UUID de disque). Confirmez la politique dans PAM/sshd et ajustez au bon niveau.

6) Symptom : “Authentication token manipulation error” en exécutant passwd

Cause racine : Système de fichiers root monté en lecture seule, ou permissions/propriété de /etc/shadow cassées, ou FS plein / inodes épuisés.

Correction : Remontez en lecture-écriture intentionnellement, corrigez le mode/propriétaire/groupe de /etc/shadow, et vérifiez l’espace libre avec df -h et df -i.

7) Symptom : Le système démarre, mais les services échouent et sudo se fige

Cause racine : DNS cassé ou configuration NSS (p.ex. pointant vers LDAP/SSSD mort) provoquant des blocages ; sudo déclenche souvent des résolutions user/group.

Correction : En rescue/chroot, inspectez /etc/nsswitch.conf, la config SSSD, et assurez-vous que l’auth locale par fichiers fonctionne toujours. Envisagez de désactiver temporairement la dépendance d’auth distante pour reprendre le contrôle.

8) Symptom : Boucle de démarrage après mise à jour du noyau, impossible d’atteindre l’invite

Cause racine : initramfs sans pilotes de stockage, crypttab cassé, ou modules noyau incompatibles.

Correction : Démarrez un noyau plus ancien depuis GRUB si disponible. En rescue, chroot et exécutez update-initramfs -u -k all, puis update-grub.

Listes de contrôle / plans pas à pas

Plan A : Il vous faut juste root (pas de problèmes de boot/stockage)

1. Démarrez le rescue target depuis GRUB ou le rescue de l’installeur.
2. Exécutez lsblk et identifiez le volume root correct.
3. Montez root en lecture seule sur /mnt. Confirmez que /mnt/etc/os-release correspond à l’hôte que vous pensez réparer.
4. Montez /boot, /boot/efi, et /var si séparé.
5. Faites les bind mounts /dev, /proc, /sys, /run, puis chrootez.
6. Vérifiez l’état de root : passwd -S root et chage -l root.
7. Définissez un mot de passe root temporaire fort : passwd root.
8. Validez sudoers : visudo -c. Corrigez si nécessaire.
9. Quittez le chroot, démontez proprement, redémarrez.
10. Après connexion, tournez les identifiants correctement et documentez les changements.

Plan B : Le système tombe en emergency mode (fstab / blocages de montage)

1. Ne réinitialisez pas encore les mots de passe. Traitez-le comme un incident de dépendance au démarrage.
2. Montez root en lecture seule et lisez le journal pour les dernières erreurs de boot.
3. Inspectez /etc/fstab pour des UUIDs obsolètes, des montages réseau inaccessibles, ou des disques manquants.
4. Utilisez blkid pour confirmer les identifiants et les corriger.
5. Pour les montages non critiques, ajoutez nofail et x-systemd.device-timeout=10s pour éviter de bloquer le démarrage.
6. Remontez root en lecture-écriture seulement pour appliquer le changement minimal.
7. Redémarrez et validez que le démarrage atteint le target multi-user.

Plan C : Root chiffré / LVM qui ne remonte pas

1. En rescue, confirmez que le device chiffré est visible (lsblk et dmesg).
2. Déverrouillez avec cryptsetup luksOpen ; vérifiez le statut.
3. Activez LVM : vgscan, vgchange -ay.
4. Montez root et chrootez correctement.
5. Vérifiez /etc/crypttab, les hooks initramfs, et reconstruisez initramfs.
6. Mettez à jour la config GRUB si nécessaire, puis redémarrez.

Plan D : SSH cassé mais accès local disponible

1. Validez la configuration SSH avec sshd -t (depuis le chroot si besoin).
2. Confirmez que les clés d’hôte existent et que les permissions sont correctes dans /etc/ssh.
3. Préférez restaurer l’accès par clé d’un utilisateur admin connu plutôt que d’activer le login root par mot de passe.
4. Une fois l’accès stable, envisagez des ajustements de politique et du durcissement.

FAQ

1) Dois-je utiliser rescue.target ou emergency.target ?

Utilisez rescue.target quand vous voulez un système minimal mais avec des services et montages plus normaux.
Utilisez emergency.target quand les montages sont cassés ou que vous suspectez fstab comme cause ; il réduit les dépendances et vous donne une shell plus vite.

2) Est-ce “sûr” de réinitialiser le mot de passe root en mode rescue ?

Ce n’est sûr qu’après avoir prouvé que vous avez monté le bon système de fichiers root et que le FS est sain.
C’est risqué opérationnellement car cela change la posture de sécurité. Utilisez un mot de passe temporaire, enregistrez-le dans votre coffre d’incident, faites-le tourner ensuite, et envisagez de reverrouiller root si c’est la politique.

3) Pourquoi ai-je “Authentication token manipulation error” depuis passwd ?

Le plus souvent : le système de fichiers est monté en lecture seule, le disque est plein, ou les permissions/propriété de /etc/shadow sont incorrectes.
En mode rescue, il est courant d’oublier que vous avez monté / en ro. Cette erreur indique que le système ne peut pas écrire la base de données d’identifiants.

4) Puis-je éditer directement /etc/shadow ?

Vous pouvez, mais vous ne devriez pas à moins de vraiment savoir ce que vous faites. Utilisez passwd pour gérer le hachage et le verrouillage de fichier correctement.
Si vous devez éditer, assurez-vous des permissions et du format corrects — une ligne malformée peut casser les connexions pour tous.

5) J’ai corrigé sudoers mais sudo échoue encore après reboot. Pourquoi ?

Vérifiez les délais de résolution de noms (NSS/SSSD/LDAP) et les lookups. sudo consulte l’appartenance user/groupe et peut se bloquer si les fournisseurs d’identité distants sont inaccessibles.
Si nécessaire, assurez-vous temporairement que /etc/passwd//etc/group restent des chemins d’auth locaux fonctionnels.

6) Quand dois-je lancer fsck ou xfs_repair ?

Lancez-les quand vous avez des preuves : échecs de montage, erreurs I/O, ou messages de journal indiquant une corruption.
Pour les systèmes ext, fsck est normal. Pour XFS, utilisez xfs_repair (souvent nécessite démontage). Ne lancez pas de réparations sur un FS monté sauf si l’outil le supporte explicitement.

7) Je suis sur une VM distante sans saisie de mot de passe pour LUKS. Que faire ?

C’est une contrainte de conception, pas un tour de rescue. Vous avez besoin d’un moyen de fournir la passphrase à distance (console virtuelle), d’utiliser un keyfile avec récupération sécurisée au démarrage,
ou de repenser le workflow de déverrouillage au boot. Le mode rescue peut diagnostiquer, mais il ne peut pas inventer un clavier que vous n’avez pas.

8) Dois-je réinstaller GRUB lors de la récupération root ?

Pas à moins que vous ayez un symptôme de bootloader. Les réinstallations GRUB sont invasives et peuvent perturber des setups de boot complexes.
Si le système atteint une invite de connexion, votre bootloader n’est pas la cause de l’accès root.

9) Comment confirmer que j’ai monté le bon root avant de changer quoi que ce soit ?

Vérifiez /mnt/etc/os-release, /mnt/etc/hostname, et comparez les UUID de disque avec votre inventaire.
Vérifiez aussi la présence des artefacts de boot attendus (/mnt/boot) et que findmnt -R /mnt correspond à votre schéma de partition connu.

10) Puis-je récupérer en ajoutant init=/bin/bash au boot ?

Parfois, mais c’est brutal et contourne l’initialisation normale. Cela peut aussi produire des états confus avec des disques chiffrés et des attentes systemd.
Préférez systemd.unit=emergency.target ou le rescue de l’installeur, puis faites une réparation propre basée sur chroot.

Étapes suivantes après votre retour

Retrouver root n’est pas la ligne d’arrivée ; c’est reprendre la capacité de faire des changements délibérés. Faites trois choses avant de déclarer victoire :

1. Stabiliser l’accès : Assurez-vous d’au moins deux chemins admin indépendants (console + SSH par clé pour un utilisateur admin). Évitez de dépendre d’un seul mot de passe.
2. Corriger la cause réelle : Si le déclencheur était fstab, PAM, initramfs, ou une dépendance à un fournisseur d’identité, traitez cela par un changement justifié par des preuves.
3. Laisser des traces : Écrivez ce que vous avez changé, pourquoi, et comment revenir en arrière. Mettez-le là où votre équipe le trouvera réellement lors du prochain incident.

La meilleure rescue est celle dont vous n’aurez besoin qu’une seule fois. Après l’incident, investissez dans un partitionnement prévisible, des procédures d’upgrade testées, et une politique pour root/sudo qui soit documentée, appliquée, et ennuyeuse.
L’ennui, c’est bien. Les démarrages ennuyeux.