Réinitialiser le mot de passe root sous Linux : console, SELinux et audit
EdwardMoon
Ce guide explique comment réinitialiser le mot de passe root sur RHEL 8 et les versions de Rocky Linux utilisant la même procédure de récupération avec rd.break. Ne l’appliquez pas directement à Ubuntu, à une autre configuration initramfs ou aux politiques d’authentification de distributions plus récentes : consultez la procédure officielle de la version concernée. Depuis une console autorisée, le mode de récupération rd.break permet de rendre le système de fichiers racine accessible en écriture, de changer le mot de passe, puis de vérifier le réétiquetage SELinux et le démarrage. Avant de copier une commande, vérifiez la cible, vos autorisations, le périmètre du changement et la méthode de récupération. Ce guide rassemble les concepts, l’ordre des opérations, les blocs de code, la validation et le dépannage dans une même procédure d’exploitation.
Les valeurs des exemples servent à illustrer la procédure. Adaptez les noms d’hôtes, les utilisateurs, les périphériques, les chemins et les plages réseau à votre environnement. Avant toute modification en production, sauvegardez l’état et la configuration actuels, puis assurez-vous de disposer d’une console ou d’une autre session d’administration.

Réinitialiser le mot de passe root sous Linux : concepts et périmètre
Pour appliquer correctement les paramètres liés à la réinitialisation du mot de passe root, il faut comprendre les relations entre les composants, au-delà du nom des commandes. Recoupez les résultats des contrôles, les fichiers de configuration, les processus en cours, les journaux et les réponses réelles des services.
| Domaine | Principe d’exploitation |
|---|---|
| Identifiants | Les UID/GID, davantage que les noms d’utilisateurs, déterminent la propriété des fichiers et les droits des processus. |
| Politique d’authentification | Combinaison de shadow, PAM, expiration du mot de passe, verrouillage et shell de connexion. |
| Cycle de vie des droits | Création, modification, inactivité, départ et revue régulière des autorisations sudo. |
Points essentiels à retenir
- L’accès à une console physique ou virtuelle confère déjà des pouvoirs importants.
- Consignez le motif du changement, son responsable et l’heure de l’intervention.
- Après le redémarrage, utilisez un compte personnel et sudo plutôt qu’une connexion SSH directe en root.
Réinitialiser le mot de passe root sous Linux : contrôles préalables
- Relevez les UID/GID, groupes, répertoires personnels et propriétaires des fichiers existants pour détecter les conflits.
- Distinguez les comptes dédiés aux services des comptes personnels et définissez les règles de shell, de répertoire personnel, d’expiration et de verrouillage.
- Ne placez pas directement les hachages de mots de passe dans les arguments de commande ou les scripts ; utilisez une méthode de saisie sûre.
- Après le changement, vérifiez une nouvelle session, la prise en compte des groupes, le périmètre sudo et l’accès aux fichiers du service.
- Verrouillez les comptes et clés inutilisés, puis auditez régulièrement la propriété des fichiers, les groupes et les dernières connexions.
Réinitialiser le mot de passe root sous Linux : commandes et exemples
Exécutez les commandes ci-dessous étape par étape. La réussite d’un bloc de code ne garantit pas que l’étape suivante soit sûre. Vérifiez les sorties, les codes de retour et les journaux avant de poursuivre.
Étape 1 : vérifier l’état actuel
# Dans le menu GRUB de la console, appuyez sur e.
# Ajoutez rd.break à la fin de la ligne du noyau commençant par linux.
# Démarrez avec Ctrl+x, puis exécutez les commandes ci-dessous dans le shell de récupération.
mount -o remount,rw /sysroot
chroot /sysroot
Étape 2 : modifier la configuration en sécurité
passwd root
touch /.autorelabel
mount -o remount,ro /
exit
exit
Étape 3 : vérifier le résultat
Le réétiquetage SELinux peut prendre du temps et être suivi d’un redémarrage. Ne coupez pas l’alimentation pendant cette opération ; attendez l’écran de connexion normal. Connectez-vous depuis la console avec le nouveau mot de passe, puis vérifiez l’état avec les commandes suivantes. Il n’est pas nécessaire d’autoriser les connexions SSH en root.
getenforce
sudo passwd -S root
sudo journalctl -b -p warning --no-pager
sudo sshd -T | grep permitrootlogin
Validation opérationnelle et dépannage
La vérification ne s’arrête pas au message de réussite d’une commande. Contrôlez l’identité qui exécute l’opération, l’état réel des fichiers, processus et sockets, les journaux du service et son fonctionnement du point de vue utilisateur. En cas d’échec, comparez la dernière modification à l’état de référence connu plutôt que de répéter la même commande.
- Des noms d’utilisateurs identiques avec des UID différents produisent des incohérences de droits sur les fichiers partagés et NFS.
- Les changements de groupes ne sont pas immédiatement pris en compte dans les sessions déjà ouvertes : vérifiez-les dans une nouvelle session.
- Distinguez le verrouillage du compte, les restrictions du shell et la possibilité pour un compte de service d’exécuter son programme.
Liste de contrôle d’exploitation
- L’hôte, l’utilisateur, le périphérique, le fichier ou le service cible est clairement identifié.
- La configuration actuelle et les données importantes sont sauvegardées dans un emplacement distinct.
- Le compte utilisé dispose des privilèges minimaux et le périmètre réseau est limité au nécessaire.
- Les exemples de commandes et de configuration ont été adaptés à l’environnement réel.
- Le fonctionnement a été vérifié depuis une nouvelle session ou un client indépendant.
- Les journaux, la supervision, les sauvegardes, la procédure de récupération et les responsables ont été vérifiés.
Documentation officielle et guides associés
- Red Hat RHEL 8 : récupérer le mot de passe root avec rd.break
- Manuel Linux useradd(8)
- Manuel Linux usermod(8)
- Authentification par clé SSH et sécurité des comptes
- Exploitation OpenLDAP : comptes, TLS et sauvegardes
Une réinitialisation du mot de passe root sous Linux n’est pas terminée simplement parce qu’une commande a réussi une fois. Les paramètres doivent persister après un redémarrage ou dans une nouvelle session, les droits et l’exposition doivent correspondre à l’objectif, et les erreurs doivent pouvoir être détectées et corrigées par un retour arrière sûr.