reconstruction complete sans echec, et correction : ssh_hardening declarait deja

Deuxieme reconstruction from-zero : zero echec, zero injoignable sur les 14
hotes, d'un seul trait — creation, amorcage du socle, trente couches. La
premiere avait demande six corrections. Les cinq devis : CONFORME.

D-71 se lit dans les chiffres : infra-pki-01 changed=3, infra-dns-01
changed=1, deja montes par _amorcer-socle.

CORRECTION. J'ai ecrit hier que MaxStartups/MaxSessions « ne viennent d'aucun
role, elles sont dans le gabarit ». C'est FAUX : j'avais grepe ssh_baseline
seul. ssh_hardening les pose depuis toujours, en dur dans son template. Le
depot declarait bien son durcissement ; ce qu'il ne faisait pas, c'est
l'exposer — des valeurs ecrites dans un fichier de rendu sont invisibles a qui
lit les defaults.

Et ma premiere correction avait EMPIRE les choses : ajouter ces cles a
ssh_baseline creait deux fichiers, deux roles, une meme directive et deux
valeurs. Retire. Elles sont maintenant des variables de ssh_hardening.

Mesure finale sur les 14 : logingracetime 20, maxsessions 10, maxstartups
10:30:60 — identique partout.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,5 +1,40 @@
 # CHANGELOG — Set-OPS
 
+## 2026-08-09 — Reconstruction complète d'un seul trait, et une correction que je me dois
+
+**Deuxième reconstruction from-zero : zéro échec, zéro injoignable, sur les quatorze
+hôtes.** La première avait demandé six corrections et autant de reprises ; celle-ci est
+allée au bout d'un seul trait, `make myDay` compris — création, amorçage du socle,
+trente couches.
+
+D-71 se lit dans les chiffres : `infra-pki-01` à `changed=3` et `infra-dns-01` à
+`changed=1`, parce qu'ils étaient déjà debout, montés par `_amorcer-socle` avant que la
+flotte ne démarre. Les couches sont passées à vide sur eux.
+
+Les cinq devis : **CONFORME**.
+
+**La correction.** J'ai écrit hier que `MaxStartups` et `MaxSessions` « ne viennent d'aucun
+rôle, elles sont dans le gabarit doré ». **C'est faux.** J'avais grepé `ssh_baseline` seul.
+C'est `ssh_hardening` qui les pose — depuis toujours, dans
+`templates/20-setops-hardening.conf.j2`, **en dur** :
+
+```
+MaxSessions 2
+MaxStartups 5:30:20
+```
+
+Le dépôt déclarait donc bien son durcissement. Ce qu'il ne faisait pas, c'est l'exposer :
+des valeurs écrites dans un fichier de rendu sont invisibles à qui lit les `defaults`, et
+inajustables sans toucher au template. Elles sont désormais des variables
+(`ssh_hardening_max_startups`, `ssh_hardening_max_sessions`).
+
+Et ma première correction avait **empiré** les choses : en ajoutant ces mêmes clés à
+`ssh_baseline`, j'avais créé deux fichiers gérés par deux rôles déclarant la même directive
+avec des valeurs différentes. Retiré.
+
+**Mesure finale, sur les quatorze** : `logingracetime 20  maxsessions 10  maxstartups
+10:30:60` — identique partout, et conforme à ce qui est déclaré.
+
 ## 2026-08-09 — « Banner exchange » : ce n'était ni le réseau, ni l'hôte, ni sshd
 
 La course qui avait interrompu deux déploiements est **comprise**, cette fois — parce que

roles/ssh_hardening/defaults/main.yml

@@ -7,3 +7,24 @@ ssh_hardening_client_alive_interval: 300
 ssh_hardening_client_alive_count_max: 2
 ssh_hardening_max_auth_tries: 3
 ssh_hardening_login_grace_time: "20s"
+
+# --- Limites de connexion : VARIABLES, plus ecrites en dur dans le gabarit ---------
+#
+# Elles valaient `5:30:20` et `2`, en dur dans le template du role — donc invisibles a
+# qui lit les `defaults`, et impossibles a ajuster sans modifier un fichier de rendu.
+#
+# Elles ont coupe la voie d'administration : au-dela de 5 connexions NON AUTHENTIFIEES
+# simultanees, sshd en refuse une partie SANS envoyer de banniere, et le client rapporte
+# « Connection timed out during banner exchange » — un message qui accuse le reseau pour
+# un refus applicatif. Deux deploiements interrompus le 2026-08-09, sur des hotes qui
+# n'avaient ni redemarre ni perdu leur reseau.
+#
+# Les valeurs ci-dessous sont plus LARGES, et c'est un arbitrage assume : `MaxStartups`
+# protege d'une inondation de connexions, or le port 22 n'est atteignable que depuis le
+# reseau d'administration (`nftables_admin_ssh`, D-54). Le risque qu'il couvre l'est deja
+# en amont ; celui qu'il creait — perdre la main sur la flotte — ne l'etait pas.
+#
+# Le client, lui, ouvre desormais tres peu de connexions (`pipelining` + `ControlPersist`
+# dans `ansible.cfg`) : ces valeurs sont la marge, pas la contrainte.
+ssh_hardening_max_startups: "10:30:60"
+ssh_hardening_max_sessions: 10

roles/ssh_hardening/templates/20-setops-hardening.conf.j2

@@ -23,5 +23,5 @@ ClientAliveInterval {{ ssh_hardening_client_alive_interval }}
 ClientAliveCountMax {{ ssh_hardening_client_alive_count_max }}
 MaxAuthTries {{ ssh_hardening_max_auth_tries }}
 LoginGraceTime {{ ssh_hardening_login_grace_time }}
-MaxSessions 2
-MaxStartups 5:30:20
+MaxSessions {{ ssh_hardening_max_sessions }}
+MaxStartups {{ ssh_hardening_max_startups }}