---
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"

# --- 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