2026-06-24 20:17:46 -04:00
|
|
|
---
|
|
|
|
|
ssh_hardening_port: 22
|
|
|
|
|
ssh_hardening_password_authentication: "no"
|
|
|
|
|
ssh_hardening_permit_root_login: "no"
|
|
|
|
|
ssh_hardening_pubkey_authentication: "yes"
|
|
|
|
|
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"
|
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>
2026-08-09 13:45:24 -04:00
|
|
|
|
|
|
|
|
# --- 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
|
