docs: manuel d'exploitation pour la perte d'accès SSH au serveur (#44) #132

Merged

olivier merged 1 commit from lenaic/44-runbook-acces-serveur into develop

2026-09-04 07:20:29 +00:00

lenaic commented

2026-09-03 22:31:35 +00:00

Owner

Ce que ça change

Le geste le plus sensible du projet n'avait pas son manuel : quand l'accès SSH au serveur tombe, aucun des neuf autres ne se joue. Ce manuel apprend à diagnostiquer sans accès, et surtout à lire ce que le client ne dit pas.

Contribue au #44. Ne le ferme pas : le ticket couvre un manuel par geste sensible, celui-ci en est un.

Preuve

Toutes les commandes publiées ont été exécutées, sur le serveur ou contre lui, pendant et après l'incident du 3 septembre.

$ exec 3<>/dev/tcp/10.105.200.41/22; head -1 <&3
SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.18

$ ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:BGXH61O4BGi4XWSjArB7DuH+LRszNzvOGfOjWd2mFhM  (inchangée depuis le 27/08)

$ uptime -s
2026-09-01 08:34:32          (aucun redémarrage le 03/09)

$ grep -E '^(Start-Date|Upgrade)' /var/log/apt/history.log | tail -2
Start-Date: 2026-09-03  06:31:59
Upgrade: openssh-client (1:9.6p1-3ubuntu13 -> 1:9.6p1-3ubuntu13.18), ssh, openssh-server

$ for p in 22 443 9999; do ... done
22    OUVERT  27 ms
443   ECHEC   9003 ms
9999  ECHEC   9003 ms

Les trois dernières sorties sont celles qui démontent les fausses pistes suivies le matin du 3 : les clés d'hôte n'avaient pas changé, la machine n'avait pas redémarré, et le déclencheur était la mise à jour automatique.

Relecture

Un pair a relu et laissé un commentaire, même court
Ses remarques sont traitées, ou une réponse explique pourquoi elles ne le sont pas

Ce qui suit le code

docs/runbooks/ mis à jour, un geste d'exploitation a changé

Où regarder en priorité

La correction dans docs/FORGE.md. La phrase « le port 22 de l'hôte n'a pas été modifié par ce déploiement » était vraie le 31 août et est devenue celle qui a coûté deux heures le 3 septembre. Je l'ai corrigée plutôt que retirée, pour que quelqu'un qui s'en souvienne tombe sur le rectificatif. Dites-moi si vous préférez la supprimer.

La section 6 documente la voie de retour par l'exécuteur Actions, qui est aussi le trou de sécurité du #103. Je l'ai assortie d'un avertissement : le jour où ce trou sera fermé, il faudra la remplacer par l'accès console, pas simplement la supprimer. Il faut toujours un chemin de secours hors SSH.

## Ce que ça change Le geste le plus sensible du projet n'avait pas son manuel : quand l'accès SSH au serveur tombe, aucun des neuf autres ne se joue. Ce manuel apprend à diagnostiquer sans accès, et surtout à lire ce que le client ne dit pas. Contribue au #44. Ne le ferme pas : le ticket couvre un manuel par geste sensible, celui-ci en est un. ## Preuve Toutes les commandes publiées ont été exécutées, sur le serveur ou contre lui, pendant et après l'incident du 3 septembre. ``` $ exec 3<>/dev/tcp/10.105.200.41/22; head -1 <&3 SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.18 $ ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub 256 SHA256:BGXH61O4BGi4XWSjArB7DuH+LRszNzvOGfOjWd2mFhM (inchangée depuis le 27/08) $ uptime -s 2026-09-01 08:34:32 (aucun redémarrage le 03/09) $ grep -E '^(Start-Date|Upgrade)' /var/log/apt/history.log | tail -2 Start-Date: 2026-09-03 06:31:59 Upgrade: openssh-client (1:9.6p1-3ubuntu13 -> 1:9.6p1-3ubuntu13.18), ssh, openssh-server $ for p in 22 443 9999; do ... done 22 OUVERT 27 ms 443 ECHEC 9003 ms 9999 ECHEC 9003 ms ``` Les trois dernières sorties sont celles qui démontent les fausses pistes suivies le matin du 3 : les clés d'hôte n'avaient pas changé, la machine n'avait pas redémarré, et le déclencheur était la mise à jour automatique. ## Relecture - [ ] Un pair a relu et laissé un commentaire, même court - [ ] Ses remarques sont traitées, ou une réponse explique pourquoi elles ne le sont pas ## Ce qui suit le code - [x] `docs/runbooks/` mis à jour, un geste d'exploitation a changé ## Où regarder en priorité La correction dans `docs/FORGE.md`. La phrase « le port 22 de l'hôte n'a pas été modifié par ce déploiement » était vraie le 31 août et est devenue celle qui a coûté deux heures le 3 septembre. Je l'ai corrigée plutôt que retirée, pour que quelqu'un qui s'en souvienne tombe sur le rectificatif. Dites-moi si vous préférez la supprimer. La section 6 documente la voie de retour par l'exécuteur Actions, qui est aussi le trou de sécurité du #103. Je l'ai assortie d'un avertissement : le jour où ce trou sera fermé, il faudra la remplacer par l'accès console, pas simplement la supprimer. Il faut toujours un chemin de secours hors SSH.

lenaic added 1 commit

2026-09-03 22:31:35 +00:00

docs: manuel d'exploitation pour la perte d'accès SSH au serveur

Intégration / Qualité du code Python (pull_request) Successful in 56s

Details

Intégration / Tests unitaires et couverture (pull_request) Successful in 59s

Details

Intégration / Dépendances Python et inventaire applicatif (pull_request) Successful in 1m29s

Details

Intégration / Images épinglées par version (pull_request) Successful in 3s

Details

Intégration / Dépendances du tableau de bord (pull_request) Successful in 3m12s

Details

Intégration / Aucun secret commité (pull_request) Successful in 3s

Details

Intégration / Tableau de bord (pull_request) Successful in 3m44s

Details

99f9f37d56

L'incident du 3 septembre a coûté 1 h 34 d'accès administrateur et deux heures
de diagnostic sur trois fausses pistes. Rien de tout cela ne vivait ailleurs
que dans le journal d'équipe, qui est un récit et non un manuel. Ce geste-là
n'avait pas le sien alors que c'est le plus sensible de tous : quand il échoue,
aucun des neuf autres manuels ne se joue.

Le manuel tient en neuf sections et ne suppose aucun accès au serveur pour ses
quatre premières. Il apprend surtout à lire ce que le client ne dit pas :
« Permission denied (publickey) » décrit un refus et jamais un interlocuteur,
et une empreinte de clé d'hôte qui change ne signifie pas que le serveur a
changé les siennes. Une bannière « OpenSSH_10.0 » nue, sans suffixe de
distribution, désigne une image Alpine donc un conteneur, pas le sshd du
système. Un port fermé répond en quelques millisecondes, un port filtré fait
patienter : la confusion entre les deux a produit un faux diagnostic.

Suivent la cause connue et son déclencheur, la mise à jour automatique qui
arrête ssh.service et laisse le conteneur prendre le port, la voie de retour
par l'exécuteur Actions avec la mise en garde qu'elle est le trou du #103, la
remise en état dans l'ordre, et ce qu'il ne faut pas faire.

FORGE.md affirmait que le port 22 de l'hôte n'était pas modifié par le
déploiement. C'était vrai le 31 août et c'est devenu la phrase qui a coûté deux
heures. Elle est corrigée plutôt que retirée, avec le renvoi vers le manuel et
vers la neutralisation posée par la #101.

Toutes les commandes publiées ont été exécutées, sur le serveur ou contre lui.

Ticket #44.