Désactiver la prise en charge SSH des known_hosts utilisateur
Force sshd à ignorer le fichier ~/.ssh/known_hosts de chaque utilisateur en positionnant IgnoreUserKnownHosts yes.
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
Lorsque l'authentification par hôte (host-based) est autorisée, un fichier ~/.ssh/known_hosts contrôlé par l'utilisateur peut servir à contourner la liste des hôtes de confiance du système. En positionnant IgnoreUserKnownHosts yes, sshd ne fait confiance qu'au fichier système /etc/ssh/ssh_known_hosts : un attaquant qui injecterait des entrées dans le fichier d'un utilisateur ne pourra ni s'authentifier en tant qu'un autre utilisateur ni usurper un hôte de confiance. C'est une mesure de défense en profondeur qui garantit qu'une connexion distante exige toujours un mot de passe même si la confiance par hôte est mal configurée ailleurs.
Ce que vérifie Pavois
Pavois vérifie la valeur effective à l'exécution en analysant sshd -T, qui affiche la configuration entièrement résolue. Lire uniquement /etc/ssh/sshd_config raterait les valeurs définies dans les drop-ins Include sous /etc/ssh/sshd_config.d/ ou dans des blocs Match contextuels, 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(/^ignoreuserknownhosts\s+yes$/i) }
endComment vérifier qu’elle est appliquée
Exécutez sudo sshd -T | grep -i ignoreuserknownhosts. La sortie attendue est ignoreuserknownhosts yes.
Inspecter et investiguer
Les tentatives d'authentification et les décisions associées sont consignées par sshd dans /var/log/secure (famille RHEL), suivez-les en direct avec journalctl -u sshd -f. Les rejets d'authentification par hôte y apparaissent avec des messages relatifs au traitement des known_hosts utilisateur.
Remédiation
pavois harden apply définit la directive sshd_setting ignoreuserknownhosts sur yes dans un drop-in géré, valide le fichier avec sshd -t -f %{path}, puis déclenche un reload du service ssh pour que le changement prenne effet sans couper les sessions existantes.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| directive | ignoreuserknownhosts |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | yes |
| 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 IgnoreUserKnownHosts à sa valeur par défaut no permet aux utilisateurs d'alimenter leurs propres entrées d'hôtes de confiance, ce qui peut servir à contourner les contrôles d'accès par hôte et à usurper des machines de confiance. Appliquer la règle présente peu de risque : elle n'affecte que l'authentification par hôte et ne modifie ni les connexions par mot de passe ni par clé publique. Précaution : si vous dépendez de l'authentification par hôte (HostbasedAuthentication yes) avec des known_hosts par utilisateur, ces flux cesseront de fonctionner, migrez d'abord ces entrées dans le fichier système /etc/ssh/ssh_known_hosts. Le reload (et non un restart) 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 |
|---|---|---|---|---|
| NIST | 3.1.12 | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
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.