Ne perdez pas l'accès : sauvegardez clés et mots de passe
Comment sont structurés les accès à la machine, pourquoi une seconde clé SSH est nécessaire, où stocker le mot de passe root et que faire si l'unique clé est perdue.
Mis à jour le 23 août 2026
Perdre l'accès à votre machine arrive plus souvent qu'un piratage. Un ordinateur portable tombe en panne, vous réinstallez le système d'exploitation, vous effacez le répertoire .ssh, vous oubliez le mot de passe. La différence entre "ennuyeux" et "une catastrophe" est d'avoir préparé une seconde voie d'accès à l'avance.
Trois voies d'accès
| Chemin | Comment vous y accédez | Quand cela fonctionne |
|---|---|---|
| SSH | Clé ou mot de passe | Tant que le réseau est actif et que sshd est configuré |
| Console dans le panneau | Mot de passe root | Toujours, même si le réseau n'a jamais fonctionné |
| Disque de secours | Aucun mot de passe, connexion root | Toujours, même si le système ne démarre pas |
Les deux chemins suivants ne dépendent pas de vos paramètres SSH ou de votre pare-feu — c'est précisément pourquoi vous ne pouvez jamais vous verrouiller définitivement hors d'une machine Millida VDS. Mais pour les utiliser, vous avez besoin de l'accès à votre compte Millida et du mot de passe root.
Une seconde clé SSH
La liste des clés dans l'onglet "Access" du panneau à /hosting/vds/m/<id> est remplacée dans son intégralité. Ajoutez les deux en même temps : celle qui fonctionne et celle de secours.
ssh-keygen -t ed25519 -C "work laptop"
ssh-keygen -t ed25519 -f ~/.ssh/id_backup -C "spare"
cat ~/.ssh/id_ed25519.pub ~/.ssh/id_backup.pub
Conservez la clé de secours quelque part autre que sur la clé principale : un gestionnaire de mots de passe, une archive chiffrée, une clé USB dans un tiroir. Une clé sur le même ordinateur que la clé principale n'est pas une clé de secours.
Testez les deux clés juste après les avoir ajoutées :
ssh -i ~/.ssh/id_backup root@<address>
Une clé de secours non testée n'est pas une clé de secours.
Le mot de passe root
Il est stocké de manière chiffrée et affiché lorsque vous cliquez sur un bouton dans l'onglet "Access". Copiez-le dans un gestionnaire de mots de passe : en cas d'urgence, ouvrir le panneau et cliquer sur le bouton ne sera pas toujours rapide, et taper une longue chaîne dans la console VNC est laborieux.
Le mot de passe fonctionne toujours pour la console et pour su - même après avoir désactivé la connexion SSH root.
Ce qu'il faut stocker séparément de la machine
- Les clés SSH privées et leur phrase de passe.
- Le mot de passe root.
- L'accès à votre compte Millida et son second facteur.
- Les identifiants de connexion de votre bureau d'enregistrement de domaine et de DNS.
- Les sauvegardes et configurations de bases de données : nous ne faisons pas de sauvegardes automatiques de votre machine — vous faites les copies vous-même.
Une façon simple de pousser régulièrement des données hors site :
pg_dump -Fc mydb > /root/dump.pgc
rsync -az /root/dump.pgc backup@other-machine:/backups/
Si vous perdez l'accès
- Vous avez perdu la clé mais conservez le mot de passe root — connectez-vous via la console du panneau et ajoutez une nouvelle clé à
~/.ssh/authorized_keys. - Vous avez oublié le mot de passe aussi — cliquez sur "Change password" dans l'onglet "Access". Le panneau en émettra un nouveau et redémarrera la machine en cours d'exécution.
- Le système ne démarre pas — activez le disque de secours, montez le disque et corrigez les clés ou le mot de passe en chroot.
- Vous avez perdu l'accès à votre compte Millida — récupérez-le via la procédure standard ; une machine ne peut pas être remise sans compte, et cette protection est en votre faveur.
Erreurs courantes
- Une seule clé sur un seul appareil sans copie.
- La clé de secours stockée à côté de la clé principale.
- Vous avez remplacé les clés dans le panneau et effacé la clé fonctionnelle : la liste est remplacée dans son intégralité, donc collez-les toutes en une seule fois. Cela vous évite également un redémarrage supplémentaire — chaque sauvegarde de clé redémarre la machine en cours d'exécution.
- La phrase de passe de la clé n'est écrite nulle part.
- Le mot de passe root n'a jamais été testé dans la console.
Effectuez un exercice une fois par trimestre : connectez-vous avec la clé de secours et testez le mot de passe root via la console. Cinq minutes de vérification vous évitent une soirée de récupération.