Vérifier le propriétaire des fichiers de configuration du serveur SSH
Garantit que le répertoire drop-in SSH /etc/ssh/sshd_config.d appartient à root (uid 0).
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
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
Sur Ubuntu moderne, /etc/ssh/sshd_config se termine par Include /etc/ssh/sshd_config.d/*.conf, de sorte que les fichiers drop-in de ce répertoire surchargent la politique principale. C'est précisément la surface qu'un scanner basé sur les fichiers manque. Si un utilisateur non-root possède /etc/ssh/sshd_config.d, il peut y déposer un .conf qui réactive la connexion root ou affaiblit l'authentification, surchargeant silencieusement une configuration principale durcie. Restreindre la propriété à root (uid 0) garantit que seul le superutilisateur peut introduire des surcharges de politique SSH.
Ce que vérifie Pavois
Pavois vérifie que le répertoire réel /etc/ssh/sshd_config.d a l'uid de propriétaire 0, ignoré via only_if s'il n'existe pas. Cette règle incarne l'avantage de Pavois : les scanners basés sur les fichiers ne vérifient que sshd_config et manquent les drop-ins inclus via Include qui peuvent le surcharger silencieusement. Pavois lit le propriétaire effectif du répertoire de surcharge depuis le système de fichiers, détectant une dérive que OVAL/oscap ne regarderaient même pas.
only_if { file('/etc/ssh/sshd_config.d').exist? }
describe file('/etc/ssh/sshd_config.d') do
its('uid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%U %u' /etc/ssh/sshd_config.d. Sortie attendue : root 0. Pour couvrir aussi les drop-ins, exécutez find /etc/ssh/sshd_config.d -not -user root, il ne doit rien afficher.
Inspecter et investiguer
La propriété ne génère pas de journal continu ; interrogez-la avec stat /etc/ssh/sshd_config.d. L'effet d'un drop-in malveillant est visible en comparant la politique en vigueur via sshd -T à votre référentiel attendu. Les erreurs du service SSH et de chargement de configuration apparaissent dans /var/log/auth.log ou via journalctl -u ssh.
Remédiation
Aucun plan de durcissement automatisé n'est défini, appliquez-la donc manuellement : chown root:root /etc/ssh/sshd_config.d et, pour les fichiers de surcharge, chown root:root /etc/ssh/sshd_config.d/*.conf.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| owner | root |
|---|---|
| path | /etc/ssh/sshd_config.d |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un propriétaire non-root de ce répertoire peut surcharger silencieusement votre politique SSH durcie via un drop-in, réactivant potentiellement la connexion root distante. Restaurer la propriété root est sans danger et n'affecte pas les sessions en cours. Précaution : après avoir corrigé la propriété, exécutez sshd -t et confirmez la politique en vigueur avec sshd -T ; conservez des modes de fichiers restrictifs et gardez une session de secours ouverte avant de recharger sshd.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.1.1 | direct | per OS, see the benchmark table | haute |
| NIST | AC-17(a), AC-6(1), CM-6(a) | 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.