Désactiver la prise en charge SSH des fichiers .rhosts
Force IgnoreRhosts yes afin que SSH ignore les fichiers .rhosts et .shosts lors de l'authentification des utilisateurs.
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
Les fichiers .rhosts/.shosts implémentent une confiance basée sur l'hôte : ils permettent à un utilisateur d'un hôte nommé de se connecter sans fournir d'identifiant. Cette confiance repose sur des adresses source facilement usurpables, si bien que compromettre un hôte permet à un attaquant de rebondir trivialement vers tout hôte qui lui fait confiance. IgnoreRhosts yes indique à SSH d'ignorer entièrement ces fichiers, fermant ce chemin de mouvement latéral sans identifiant.
Ce que vérifie Pavois
Pavois lit la valeur effective via sshd -T, après chaque Include, drop-in de /etc/ssh/sshd_config.d/ et bloc Match. Un bloc Match peut réactiver la confiance rhosts pour un utilisateur ou une plage d'adresses précise ; seule la sortie résolue le révèle, contrairement à une lecture de /etc/ssh/sshd_config.
describe command('sshd -T') do
its('stdout') { should match(/^ignorerhosts\s+yes$/i) }
endComment vérifier qu’elle est appliquée
Exécutez sshd -T | grep -i '^ignorerhosts'. La sortie attendue est ignorerhosts yes.
Inspecter et investiguer
Les tentatives d'authentification basées sur l'hôte sont journalisées dans /var/log/auth.log (Debian/Ubuntu) ou journalctl -u sshd (famille RHEL) ; une connexion rhosts rejetée apparaît comme une ligne d'échec d'authentification.
Remédiation
Le plan harden de Pavois écrit la directive sshd_setting IgnoreRhosts yes dans un drop-in géré, valide avec sshd -t, puis recharge le service ssh. Appliquez-le avec pavois harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| directive | ignorerhosts |
|---|---|
| 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
Quasiment aucun impact dans un environnement moderne : la confiance .rhosts basée sur l'hôte est obsolète et presque jamais utilisée légitimement. La seule chose que cela casse est une authentification rhosts intentionnelle ; si vous en dépendez (rare), migrez d'abord vers l'authentification par clé. Le rechargement préserve les sessions actives.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 2.2.6, 5.1.11, 5.1.13 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.12, AC-17(a), CM-6(a), CM-7(a), CM-7(b) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 2.2.6 | support | 4.0.1 | 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.