Définir le nombre maximal de sondes d'activité du client SSH
Définit ClientAliveCountMax 0 pour qu'une session soit fermée dès l'expiration du premier ClientAliveInterval sans réponse.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
ClientAliveCountMax contrôle combien de sondes keepalive sans réponse sshd tolère avant de fermer une session. Le positionner à 0 signifie que la session est terminée immédiatement dès qu'une période d'inactivité de ClientAliveInterval s'écoule, garantissant que le délai d'inactivité est respecté sans tolérance et minimisant la fenêtre durant laquelle une session sans surveillance peut être détournée. C'est le pendant de ssh-set-idle-timeout ; ensemble, ils imposent une déconnexion stricte pour inactivité côté serveur.
Ce que vérifie Pavois
Pavois lit la valeur effective de clientalivecountmax depuis sshd -T, la configuration résolue du démon. Un scan de /etc/ssh/sshd_config pourrait rater une valeur définie dans un drop-in Include sous /etc/ssh/sshd_config.d/ ou dans un bloc Match, sshd -T reflète exactement ce que le démon en cours d'exécution applique.
describe command('sshd -T') do
its('stdout') { should match(/^clientalivecountmax\s+[1-3]$/i) }
endComment vérifier qu’elle est appliquée
Exécutez sudo sshd -T | grep -i clientalivecountmax. La sortie attendue est clientalivecountmax 0.
Inspecter et investiguer
Les déconnexions pour inactivité déclenchées par ce paramètre sont consignées par sshd (par exemple Timeout, client not responding / Connection closed) dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (famille RHEL) ; suivez avec journalctl -u ssh -f (ou -u sshd).
Remédiation
pavois harden apply définit la directive sshd_setting clientalivecountmax sur 0 dans un drop-in géré, la valide avec sshd -t -f %{path}, puis déclenche un reload du service ssh pour que le délai strict prenne effet sans couper les sessions actives. Il n'est efficace qu'associé à un ClientAliveInterval non nul (voir ssh-set-idle-timeout).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| directive | clientalivecountmax |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | 1 |
| verify | sshd -t -f %{path} |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Laisser ClientAliveCountMax à sa valeur par défaut (3) accorde aux sessions inactives un délai de grâce supplémentaire avant déconnexion ; le mettre à 0 rend le délai strict. Précaution : avec un délai strict, les sessions sur des réseaux instables ou à forte latence peuvent être fermées si une seule sonde keepalive est manquée lors d'une brève coupure, pour les liens instables, envisagez ServerAliveInterval côté client et exécutez les tâches longues sous tmux/screen. Assurez-vous que ClientAliveInterval est réglé sur une valeur raisonnable (par exemple 300) afin que 0 ne produise pas une déconnexion étonnamment agressive. Le reload préserve votre session SSH en cours, il n'y a donc aucun risque de blocage.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.1.7, 8.2.8, 5.1.9 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.11, AC-12, AC-17(a), AC-2(5), CM-6(a), SC-10 | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 8.2.8 | support | 4.0.1 | moyenne |
| DISA STIG | UBTU-22-255030, UBTU-24-600000 | direct | per OS STIG release | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.