Pourquoi on se retrouve dans cette situation ?

Ça arrive plus souvent qu'on ne le croit. Un changement de mot de passe mal géré, un script d'automatisation qui génère un mot de passe puis supprime le fichier temporaire avant de le sauvegarder, ou simplement un mot de passe noté quelque part qui s'est volatilisé.

Dans mon cas, c'est arrivé sur un serveur Debian 13 hébergé sur VMware ESXi : un script avait changé le mot de passe root puis effacé les fichiers temporaires avant que KeePass ne soit mis à jour. Résultat : plus d'accès SSH, plus de console distante opérationnelle.

La solution : booter en mode single-user via GRUB, qui donne un shell root sans authentification.

🔒
Attention : procédure valable uniquement sur un disque NON chiffré Sur un serveur correctement installé avec chiffrement LUKS, cette procédure est impossible : au démarrage, le système demande la passphrase LUKS avant de monter le moindre filesystem. Sans elle, vous n'avez pas de shell — même en passant init=/bin/bash dans GRUB.

C'est précisément pour ça qu'on chiffre ses disques en prod. Si votre serveur est accessible physiquement (datacenter mutualisé, ESXi partagé, VPS avec console IPMI…), le chiffrement disque est la seule protection contre cette attaque. Sans lui, n'importe qui ayant accès à la console peut devenir root en 5 minutes — comme on vient de le voir.

👉 Voir l'article : Installer un serveur Debian sécurisé avec chiffrement LUKS
⚠️
Cette procédure nécessite un accès physique ou console à la machine (IPMI, iDRAC, VMRC ESXi, console OVH...). C'est précisément pourquoi elle est sécurisée : sans accès console, un attaquant distant ne peut pas l'utiliser.

Ce qu'il vous faut

  • Un accès console à la VM ou au serveur physique (VMRC, iDRAC, IPMI, VNC…)
  • GRUB2 comme bootloader (standard sur toutes les distros modernes)
  • Environ 5 minutes

La procédure étape par étape

1

Redémarrer et accéder au menu GRUB

Redémarrez le serveur. Au démarrage, le menu GRUB s'affiche quelques secondes. Appuyez sur Échap ou maintenez Shift pour le figer si il disparaît trop vite.

2

Éditer l'entrée de boot

Sélectionnez votre entrée Linux et appuyez sur e pour éditer les paramètres du noyau.

3

Ajouter init=/bin/bash à la ligne linux

Repérez la ligne qui commence par linux (elle contient /vmlinuz). Allez en fin de ligne et ajoutez :

GRUB — éditeur de boot
linux /vmlinuz-6.12.86-amd64 root=/dev/mapper/debian-root ro quiet splash
# Modifier pour ajouter init=/bin/bash à la fin :
linux /vmlinuz-6.12.86-amd64 root=/dev/mapper/debian-root ro quiet splash init=/bin/bash

# Appuyez sur Ctrl+X pour booter avec ces paramètres
💡
Note VMware VMRC : vérifiez que le verrou numérique (Num Lock) est activé avant de taper quoi que ce soit. Sans ça, les touches du pavé numérique envoient des séquences d'échappement ANSI (^[[6~ = Page Down, ^[[D = flèche gauche…) qui se retrouvent littéralement dans votre mot de passe et le rendent inutilisable.
4

Remonter le filesystem en lecture/écriture

Le shell démarre avec le filesystem en lecture seule. Sans cette étape, passwd échouera silencieusement.

Shell root — mode single-user
bash-5.2# mount -o remount,rw /
# Aucun message = succès. Filesystem maintenant en lecture/écriture.
5

Changer le mot de passe root

Utilisez passwd sans argument — pas passwd root qui génère une erreur en single-user. Vous êtes déjà root.

Shell root — mode single-user
bash-5.2# passwd
Nouveau mot de passe :
Retapez le nouveau mot de passe :
passwd : mot de passe mis à jour avec succès
✅
Utilisez un mot de passe temporaire simple à ce stade (ex: temp123). Une fois le serveur redémarré et l'accès SSH récupéré, changez-le immédiatement pour un mot de passe fort et sauvegardez dans votre gestionnaire (KeePassXC, Bitwarden…).
6

Redémarrer normalement

Shell root — mode single-user
bash-5.2# exec /sbin/init
[ OK ] Starting system...
# Le système reboot normalement. Reconnectez-vous en SSH.

Après le redémarrage : sécurisez l'accès

Reconnecté en SSH avec le mot de passe temporaire, appliquez immédiatement un mot de passe fort. J'utilise Python avec le module secrets pour générer des mots de passe cryptographiquement sûrs :

Python 3 — générateur de mot de passe
>>> import secrets, string, math
>>> charset = string.ascii_letters + string.digits + '{$%&@^~<>*+!?#_=-'
>>> pwd = ''.join(secrets.choice(charset) for _ in range(19))
>>> print(pwd, f"— {19*math.log2(len(charset)):.1f} bits")
K7#mP&zR2xWqL@8nT$ — 120.1 bits

Erreurs courantes

  • « passwd root » → Usage: passwd [options] [LOGIN] — En single-user, tapez juste passwd sans argument.
  • Read-only filesystem — Vous avez oublié le mount -o remount,rw /. Faites-le avant passwd.
  • Mot de passe inutilisable après reboot — Num Lock désactivé sur VMRC. Les séquences ANSI (^[[6~ = Page Down, ^[[D = flèche gauche) se retrouvent littéralement dans le hash bcrypt.
  • GRUB ne s'affiche pas — Maintenez Shift au démarrage, ou configurez GRUB_TIMEOUT=5 dans /etc/default/grub.

Prévention : ne plus jamais se retrouver dans cette situation

La vraie leçon de cette expérience, c'est l'importance d'un gestionnaire de mots de passe couplé à une discipline d'écriture avant application :

  1. Générez le mot de passe
  2. Sauvegardez-le dans KeePassXC immédiatement
  3. Appliquez-le sur le serveur
  4. Vérifiez la connexion SSH avec le nouveau mot de passe avant de fermer la session courante

Avec cette discipline, la perte d'accès devient techniquement impossible — sauf défaillance matérielle.

🛡️
La vraie protection : chiffrer le disque dès l'installation. Sur un serveur avec LUKS, cette procédure ne fonctionne tout simplement pas — le système demande la passphrase de déchiffrement au boot, avant même de lancer init. C'est le seul moyen de protéger un serveur contre un attaquant ayant un accès console. Voir : Installer un serveur Debian sécurisé avec chiffrement LUKS.