Accès verrouillé : sortir par le mode secours

1. Contexte & Objectif de Terrain : le badge expiré le jour de la livraison

Imaginez un nouveau bâtiment. On vous remet un badge d’accès le matin de l’emménagement. Le soir, vous constatez que le badge est expiré depuis le premier jour, et que le guichet ne sait pas en faire un nouveau.

C’est la situation de mon premier accès à un petit serveur loué (un serveur privé virtuel, livré avec un système vide, sans aucune application). Je voulais y héberger un bot dans un conteneur Docker. Les contraintes : accès à distance par clé seulement à terme, et un pare-feu fermé sauf pour la connexion d’administration.

Source de cette histoire : le journal du projet, reconstitué après coup. Je n’ai pas d’enregistrement minute par minute de la session.

2. Anatomie de l’Échec & Fausses Pistes : un mot de passe refusé partout, et des pièges autour

Le mot de passe livré était expiré. Le compte d’administration par défaut était fourni avec un mot de passe expiré. Il était refusé à la console du fournisseur comme en connexion à distance, y compris avec le mot de passe reçu par e-mail, copié depuis la page de l’hébergeur.

Réinstaller ne résout rien. Réinstaller le serveur avec ma clé de connexion évitait le mot de passe à distance, mais pas le changement de mot de passe imposé.

Un piège de collage. Sous Windows, dans les invites de mot de passe du terminal de l’application que j’utilisais, le raccourci habituel Ctrl+V ne colle pas. Le bon raccourci est Ctrl+Maj+V. C’est la cause probable de mes refus répétés.

Des pièges de configuration autour.

• Le Bloc-notes a créé un fichier config.txt à la place de config : l’outil de connexion ignore le fichier.
• L’agent de clés de Windows doit passer en démarrage manuel avant de charger la clé.
• Le serveur était livré sans Docker ni git, avec un pare-feu inactif, et le compte par défaut n’était pas dans le groupe des administrateurs. Cela se teste avant le script d’installation, pas après.

3. Décryptage Méthodologique par l’Analogie QSE : la clé du gardien et l’essai avant l’emménagement

Dans un bâtiment, il existe toujours une procédure de secours : le gardien détient un double. On ne change pas la serrure de tout le bâtiment parce qu’un badge est expiré.

Le fournisseur propose le même dispositif : un mode secours. On démarre le serveur sur un système temporaire, on accède au disque comme à une pièce fermée dont on possède la clé, on change le mot de passe, puis on redémarre normalement.

Le mode secours est une fonction du fournisseur : le serveur démarre sur un petit système temporaire, indépendant du système installé. Le disque du serveur devient alors un simple espace de données que l’on peut ouvrir, comme un tiroir dont on possède le double de la clé. On y fait la modification nécessaire, puis on rend la main au système d’origine.

La seconde leçon est celle de tout bon responsable : tester l’accès avant d’en avoir besoin. Tester le droit d’administration avant le script d’installation, c’est comme essayer le badge de la remplaçante avant son premier jour.

4. Le Pivot Architectural & L’Implémentation Déterministe : cinq lignes dans la console du fournisseur

La sortie propre passe par le mode secours : démarrer en mode secours depuis l’interface du fournisseur (« Reboot in rescue mode »), puis exécuter quelques commandes dans la console :

mount /dev/sdb1 /mnt
chroot /mnt
passwd debian
chage -l debian
# puis redémarrage normal depuis l'interface

La première commande monte le disque du serveur. La deuxième se place dedans comme si c’était le système normal. La troisième change le mot de passe du compte. La quatrième affiche l’état du mot de passe pour vérifier qu’il n’est plus expiré.

Pourquoi tester le groupe d’administration avant le script d’installation ? Parce que ce script modifie le pare-feu, installe des logiciels et touche à la configuration d’accès : il exige des droits d’administration. Si ces droits manquent, il risque de s’arrêter en cours de route sur un serveur à moitié configuré. D’où l’ordre : tester les droits d’abord, installer ensuite.

Un second choix mérite d’être noté : le dépôt de code étant privé, le serveur reçoit une clé de déploiement en lecture seule. Une clé limitée à la lecture limite les dégâts si elle fuit.

5. Données Chiffrées, Benchmarks & Résultats Mesurés : ce que le serveur a confirmé

Après l’exécution du script d’installation lancé par moi :

• le pare-feu n’autorise que la connexion d’administration ;
• le mot de passe en connexion à distance est refusé : seule la clé entre ;
• Docker est installé, en version 29.8.2.

Un test de redémarrage du serveur a suivi : le conteneur repart seul, et le compteur d’appels (12) a survécu.

Ces mesures n’ont pas de durée associée : je n’ai pas chronométré le temps perdu avant le mode secours. Je ne l’invente pas.

6. Déploiement Zéro-Terminal (Le Mode d’Emploi pour Marc) : la fiche d’accès de secours

Aucun serveur n’est nécessaire pour appliquer cette leçon. Un document Word suffit : la fiche d’accès de secours de chaque outil critique.

Elle contient :

1. Qui détient la clé de secours (une personne, pas un service).
2. Où elle se trouve (coffre, gestionnaire de mots de passe), jamais dans un e-mail.
3. La procédure de secours en cinq lignes, écrite pour quelqu’un qui n’était pas là le jour de la mise en place.
4. La date du dernier essai. Une procédure jamais essayée est une hypothèse.

Exemple de ligne de la fiche : « outil : suivi des commandes ; détenteur de la clé de secours : une personne nommée ; emplacement : coffre de la direction ; procédure : cinq lignes, sur la fiche ; dernier essai : 3 octobre ». Un champ vide, surtout la date du dernier essai, est un écart à traiter.

Et si un mot de passe correct est refusé, vérifiez d’abord le collage (et le verrouillage des majuscules) avant de conclure que l’outil vous refuse.

7. Les 3 Règles d’Or Actionnables & Conclusion : la clé du gardien avant la serrure neuve

1. Un accès normal verrouillé dès la livraison se contourne par le mode secours, pas par une réinstallation qui ne supprime pas le changement forcé.
2. Testez les droits d’administration avant le script qui en dépend.
3. Une procédure de secours se teste avant d’en avoir besoin.

L’incident a coûté du temps, pas des données. La leçon d’amélioration continue tient dans la fiche d’accès : écrire la procédure de secours le jour où tout va bien.

Dans une organisation, on découvre trop souvent le jour d’une panne que personne ne sait qui détient le double de la clé. Le jour où tout va bien est le seul où l’on a le temps de l’écrire, de l’essayer et de dater l’essai.