Définir l'intervalle de vérification d'activité du client SSH
Définit ClientAliveInterval 300 pour que sshd sonde les sessions inactives toutes les 300 secondes, permettant la déconnexion automatique des connexions inactives.
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
Terminer rapidement les sessions SSH inactives réduit la fenêtre durant laquelle un terminal connecté et laissé sans surveillance peut être détourné par une personne disposant d'un accès physique ou réseau. Combiné à ClientAliveCountMax, ClientAliveInterval 300 fait que le démon ferme une session restée inactive pendant la durée configurée, imposant un délai d'inactivité côté serveur indépendant du comportement du client.
Ce que vérifie Pavois
Pavois lit la valeur effective de clientaliveinterval 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(/^clientaliveinterval\s+300$/i) }
endComment vérifier qu’elle est appliquée
Exécutez sudo sshd -T | grep -i clientaliveinterval. La sortie attendue est clientaliveinterval 300.
Inspecter et investiguer
Les déconnexions par expiration 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 clientaliveinterval sur 300 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 d'inactivité prenne effet sans couper les sessions actives. À associer à ssh-set-keepalive (ClientAliveCountMax 0) pour une limite d'inactivité stricte de 300 secondes.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| directive | clientaliveinterval |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | 300 |
| 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
Sans délai d'inactivité, une session SSH laissée sans surveillance peut rester ouverte indéfiniment et être détournée. Définir ClientAliveInterval 300 est globalement sûr. Précaution : des tâches interactives longues sans sortie sur le terminal (compilations, REPL, sessions BDD manuelles) peuvent être déconnectées une fois inactives, encapsulez-les dans tmux/screen, ou utilisez nohup/systemd-run pour le travail sans surveillance. Notez que le délai mesure les sondes de vivacité serveur→client, donc un trafic réel réinitialise le compteur. 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-255035, UBTU-24-600010 | 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.