← Toutes les règles
SOCLE-CLD-FSP-109// File ownershipmoyenneétat du système de fichiers

Vérifier la propriété des fichiers de clés publiques *.pub du serveur SSH

Garantit que le répertoire de configuration et de clés d'hôte SSH /etc/ssh appartient à root (uid 0).

Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 2 normes

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

Le répertoire /etc/ssh contient les clés d'hôte du serveur SSH, privées comme publiques (*.pub). Les clés d'hôte publiques sont celles que les clients épinglent pour détecter une usurpation du serveur. Si un utilisateur non-root possède ce répertoire, il peut remplacer une clé publique, ou la clé privée associée, permettant une attaque de l'homme du milieu où les clients font silencieusement confiance à un serveur malveillant. Conserver /etc/ssh sous la propriété de root (uid 0) garantit que seul le superutilisateur peut toucher aux clés qui ancrent la confiance SSH.

Ce que vérifie Pavois

Pavois vérifie que le répertoire réel /etc/ssh a l'uid de propriétaire 0, ignoré via only_if s'il est absent. Il lit le propriétaire effectif depuis le système de fichiers (stat), de sorte qu'un chown manuel sur le répertoire contenant les clés d'hôte est détecté même si aucun outil de gestion de configuration ne signale de dérive.

describe command('find /etc/ssh -name "ssh_host_*_key.pub" -type f ! -uid 0 2>/dev/null') do
  its('stdout.strip') { should eq '' }
end

Comment vérifier qu’elle est appliquée

Exécutez stat -c '%U %u' /etc/ssh. Sortie attendue : root 0. Pour vérifier aussi les fichiers de clés, exécutez find /etc/ssh -name '*.pub' -not -user root et find /etc/ssh -name 'ssh_host_*_key' -not -user root, aucun des deux ne doit rien afficher.

Inspecter et investiguer

La propriété ne produit pas de journal continu ; interrogez-la avec stat /etc/ssh. L'activité du service SSH et les avertissements liés aux clés apparaissent dans /var/log/auth.log (Debian/Ubuntu) ou via journalctl -u ssh ; sshd refuse de démarrer s'il juge la propriété/les permissions des clés d'hôte non sûres, et cette erreur y est journalisée.

Remédiation

Aucun plan de durcissement automatisé n'est défini, appliquez-la donc manuellement : chown root:root /etc/ssh et, pour couvrir le contenu, chown root:root /etc/ssh/*.pub (clés publiques) tout en laissant les clés d'hôte privées appartenir à root en mode 0600. Réinstaller openssh-server restaure également la bonne propriété.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

commandchown root /etc/ssh/ssh_host_*_key.pub 2>/dev/null || true
namechown-sshd-pub-keys
not_if[ -z "$(find /etc/ssh -name 'ssh_host_*_key.pub' -type f ! -uid 0 2>/dev/null)" ]
resourceexec
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Un propriétaire non-root de /etc/ssh peut détourner la confiance des clés d'hôte et permettre des attaques de l'homme du milieu contre tous ceux qui se connectent. Restaurer la propriété root est sans danger et n'interrompt pas les sessions SSH existantes. Précaution : n'assouplissez pas les permissions en corrigeant la propriété, les clés d'hôte privées doivent rester en mode 0600 root:root, sinon sshd refusera de démarrer ; vérifiez avec sshd -t après toute modification, et gardez une seconde session ou une console ouverte au cas où sshd devrait être redémarré.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R50direct2.0haute
CIS5.1.2, 5.1.3, 5.1.4, 5.1.5directper OS, see the benchmark tablehaute

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.

Sources & références