N'utiliser que des algorithmes d'échange de clés validés FIPS 140-2
Restreindre les KexAlgorithms de sshd à l'ensemble validé FIPS, ordonné du plus fort au plus faible : ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256.
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
L'échange de clés SSH établit les clés de session qui protègent tout le trafic ultérieur ; un échange faible compromet toute la connexion, quel que soit le chiffrement. Seuls des algorithmes approuvés FIPS peuvent être proposés. La liste est ordonnée du plus fort au plus faible (ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256) car sshd sélectionne le premier algorithme serveur pris en charge aussi par le client, cet ordre garantit la négociation du KEX le plus robuste commun et exclut les échanges faibles ou obsolètes (p. ex. SHA-1 ou petits groupes DH).
Ce que vérifie Pavois
Pavois vérifie que la sortie effective de sshd -T liste exactement kexalgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256, dans cet ordre. Interroger le démon en cours d'exécution reflète la valeur après fusion de tous les Include, des drop-ins de /etc/ssh/sshd_config.d/ et de toute politique cryptographique système, un scan de fichiers peut manquer un drop-in ou une politique réintroduisant un KEX faible.
describe command('sshd -T') do
its('stdout') { should match(/^kexalgorithms\s+ecdh\-sha2\-nistp256,ecdh\-sha2\-nistp384,ecdh\-sha2\-nistp521,diffie\-hellman\-group\-exchange\-sha256$/i) }
endComment vérifier qu’elle est appliquée
Exécuter sshd -T | grep -i '^kexalgorithms'. Sortie attendue :
kexalgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256
Inspecter et investiguer
La négociation du KEX est journalisée au niveau VERBOSE dans /var/log/auth.log (Debian/Ubuntu) ou via journalctl -u ssh. Un client ne proposant que des algorithmes non approuvés est refusé avec Unable to negotiate ... no matching key exchange method found, visible dans les mêmes journaux.
Remédiation
Pas de remédiation automatique pour cette règle, à appliquer manuellement selon la norme.
Impact & précautions
Figer la liste des KEX peut rompre les connexions de clients ne partageant aucun de ces algorithmes, notamment les clients modernes configurés uniquement pour curve25519-sha256, ou de très vieux clients bloqués sur des échanges SHA-1. Recensez d'abord vos clients et vérifiez le recouvrement, validez avec sshd -t, gardez une seconde session ouverte, et rappelez-vous qu'une politique cryptographique système peut encore contraindre la liste effective.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| NIST | AC-17(2) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| DISA STIG | UBTU-22-255060 | 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.