Imposer une renégociation fréquente des clés de session SSH
Impose au démon de renégocier les clés de session tous les 512 Mo de trafic ou toutes les heures (RekeyLimit 512M 1h). Cela borne la quantité de chiffré protégée par une même clé et la durée pendant laquelle une clé de session volée reste exploitable ; la valeur par défaut d'OpenSSH (default none) n'impose aucune limite de temps.
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.
Ce que vérifie Pavois
Pavois exécute sshd -T et exige la ligne résolue rekeylimit 536870912 3600. Notez la normalisation : ce qu'un administrateur écrit 512M 1h est affiché par le démon en octets et en secondes, ce qui illustre précisément pourquoi le contrôle lit la configuration effective plutôt qu'un fichier. sshd -T résout aussi tous les Include et drop-ins de /etc/ssh/sshd_config.d/, de sorte qu'un fichier ultérieur rétablissant default none est détecté.
describe command('sshd -T') do
its('stdout') { should match(/^rekeylimit\s+536870912\s+3600$/i) }
endComment vérifier qu’elle est appliquée
Exécutez sshd -T | grep -i rekeylimit en root. Sortie attendue :
rekeylimit 536870912 3600
536870912 correspond à 512 Mio en octets et 3600 à une heure en secondes. Un hôte non durci affiche rekeylimit 0 0 (valeur par défaut du chiffrement, aucune limite de temps).
Inspecter et investiguer
La renégociation n'est pas journalisée au niveau par défaut LogLevel INFO : c'est une renégociation transparente, dans le canal. sshd ne la trace qu'en niveau debug (rekeying %s, input ... bytes, rekey after %llu blocks), et le client montre la même chose avec ssh -vv. Il n'y a donc pas de ligne d'audit à rechercher : la preuve opposable est la valeur effective de rekeylimit elle-même.
Remédiation
Le plan de durcissement Pavois utilise la ressource sshd_setting pour positionner la directive rekeylimit à 512M 1h dans le drop-in Pavois sous /etc/ssh/sshd_config.d/. Le fichier est validé par sshd -t -f <fichier> avant d'être conservé, et tout changement déclenche un reload de ssh.service. Le démon rapporte ensuite la valeur 536870912 3600, celle que le contrôle compare.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| directive | rekeylimit |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | 512M 1h |
| 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 limite de renégociation, un même jeu de clés peut protéger un volume illimité de données pendant toute la vie d'une session (des semaines, pour un screen ou un tmux sur SSH) : une clé récupérée par un attaquant déchiffre tout ce qui suit, et les sessions de longue durée accumulent du chiffré sous une clé unique. Appliquer la limite coûte une courte renégociation tous les 512 Mo ou toutes les heures : négligeable en CPU sur du matériel doté d'AES-NI, mais mesurable sur de gros transferts SFTP soutenus avec des processeurs lents. Avant d'appliquer, surveillez les clients SSH très anciens, embarqués ou les équipements qui gèrent mal une renégociation initiée par le serveur (sshd signale alors rekeying not supported by peer) : ils peuvent couper la connexion au bout d'une heure. Le reload laisse les sessions en cours sur leurs paramètres existants ; la limite s'applique aux nouvelles sessions.