Récupérer l'accès root perdu
Perdre l'accès root arrive pour des raisons banales : mot de passe oublié, clé SSH supprimée, règle de pare-feu trop stricte, disque plein ou sshd mal configuré. La bonne réaction n'est pas de réinstaller immédiatement, car une réinstallation détruit les données. Prenez le temps de diagnostiquer par la console et de sauvegarder avant toute action irréversible.
Avant tout : localiser la panne
Répondez à ces questions avant de toucher au système :
- Le panneau montre-t-il le VPS démarré ?
- La console affiche-t-elle un écran de connexion, un noyau paniqué ou un message d'erreur ?
df -hetjournalctl -xbrévèlent-ils un disque plein ou un service en échec ?- Le port SSH est-il toujours en écoute ?
Un conteneur système ne démarre pas sur une image de secours comme un serveur dédié. Le « mode de secours » se limite à la console et aux outils déjà présents dans le système. Il faut donc d'abord constater l'état réel.
Reprendre la main par la console
Ouvrez la console noVNC depuis le dashboard. Si un compte local avec sudo existe :
sudo -iSinon, connectez-vous en root avec le mot de passe connu, ou utilisez la réinitialisation proposée par le panneau. Une fois dans le système, inspectez :
passwd -S root
ss -tlnp | grep :22
systemctl status ssh
ufw status verbose
df -hpasswd -S root révèle un compte verrouillé. ss montre si sshd écoute encore. ufw explique un blocage réseau. df détecte un disque plein qui empêche l'écriture des clés de session.
Réparer sans réseau
- Compte verrouillé :
passwd -u rootpuispasswd root. sshdarrêté :systemctl start ssh.- Configuration fautive :
sshd -t, corrigez/etc/ssh/sshd_config, puissystemctl restart ssh. - Pare-feu trop strict : autorisez le port SSH avant de réactiver, ou désactivez UFW temporairement depuis la console.
- Disque plein : supprimez des journaux ou des caches, jamais des fichiers système au hasard.
- Système de fichiers en lecture seule :
mount -o remount,rw /si le noyau le permet, puis cherchez la cause.
Après chaque correction, testez une nouvelle connexion SSH dans une seconde session sans fermer la console.
Récupérer les données
Si le système ne peut pas être réparé, sauvegardez avant de réinstaller. Depuis la console, avec le réseau rétabli, copiez l'essentiel vers un autre serveur :
tar czf /root/sauvegarde.tar.gz /var/www /etc /home
scp /root/sauvegarde.tar.gz utilisateur@DESTINATION:/chemin/Vérifiez l'archive (tar tzf) et testez son extraction ailleurs. Une sauvegarde non vérifiée n'est pas une sauvegarde.
Réinstaller en dernier recours
La réinstallation depuis le panneau remplace tout le disque : fichiers, bases, utilisateurs, clés et certificats. Elle ne se justifie que si les données sont exportées et la cause connue, sinon le problème peut revenir. Avant de confirmer, notez la configuration réseau, les noms de domaine, les ports et les services. Après la réinstallation, recréez un utilisateur sudo, une clé SSH et un pare-feu, puis restaurez vos données. En cas de doute, contactez le support via le dashboard avant de détruire le service.
Publicité
Cet article vous a-t-il aidé ?
À lire aussi
- Changer le mot de passe root d'un VPSpasswd, réinitialisation depuis le panneau et mise à jour de tous les accès qui utilisaient l'ancien mot de passe.
- Créer un utilisateur sudo et sécuriser rootadduser, groupe sudo, test de connexion et désactivation de la connexion root en SSH.
- Comprendre root, sudo et les utilisateurs LinuxPourquoi root est puissant, comment sudo délègue un privilège et comment garder une trace des actions.