Vérifier le groupe propriétaire des clés privées *_key du serveur SSH
Garantit que l'emplacement des clés privées d'hôte SSH /etc/ssh appartient au groupe dédié ssh_keys.
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
Les clés privées d'hôte SSH (/etc/ssh/ssh_host_*_key) attestent l'identité du serveur. Si un utilisateur non autorisé lit une clé privée d'hôte, il peut usurper l'identité de l'hôte lors d'une attaque de l'intercepteur et capturer silencieusement les sessions. Sur ces distributions, les clés sont protégées par le groupe dédié ssh_keys combiné à des permissions restrictives ; définir le bon groupe propriétaire sur /etc/ssh est le socle de cette protection.
Ce que vérifie Pavois
Pavois lit le groupe propriétaire réel de /etc/ssh via la ressource InSpec file et vérifie group == 'ssh_keys'. Il contrôle la propriété effective sur le disque, de sorte qu'une clé d'hôte régénérée (par ex. après ssh-keygen -A ou un re-provisionnement) au mauvais groupe est détectée même si le manifeste de déploiement semble correct.
describe command('find /etc/ssh -name "ssh_host_*_key" -type f ! -group root ! -group ssh_keys 2>/dev/null') do
its('stdout.strip') { should eq '' }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G' /etc/ssh (attendu ssh_keys) et vérifiez les clés elles-mêmes : stat -c '%n %G %a' /etc/ssh/ssh_host_*_key, les clés privées doivent être du groupe ssh_keys avec le mode 0640 (ou 0600 root:root selon le profil).
Inspecter et investiguer
Ajoutez une surveillance auditd, auditctl -w /etc/ssh -p wa -k sshd_keys, pour enregistrer les changements de propriété dans /var/log/audit/audit.log. L'utilisation des clés d'hôte par le démon SSH au démarrage est journalisée via journalctl -u sshd / /var/log/auth.log.
Remédiation
Le plan de durcissement de Pavois utilise la ressource file pour définir le groupe propriétaire de /etc/ssh à ssh_keys (équivalent à chgrp ssh_keys /etc/ssh). Appliquez-le avec pavois harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | chgrp ssh_keys /etc/ssh/ssh_host_*_key 2>/dev/null || chgrp root /etc/ssh/ssh_host_*_key 2>/dev/null || true |
|---|---|
| name | chgrp-sshd-private-keys |
| not_if | [ -z "$(find /etc/ssh -name 'ssh_host_*_key' -type f ! -group root ! -group ssh_keys 2>/dev/null)" ] |
| resource | exec |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Si les clés privées d'hôte sont lisibles par le mauvais groupe, un attaquant qui les lit peut usurper l'identité du serveur. Définir le groupe à ssh_keys est la configuration attendue et prise en charge, sans perturbation de SSH. Précautions : le groupe ssh_keys doit exister (fourni avec openssh-server sur ces distributions) ; conservez les clés privées au mode 0640 groupe ssh_keys sans jamais les rendre lisibles par tous, et évitez un verrouillage de session en gardant une connexion SSH ouverte pendant la modification de propriété des clés et le redémarrage de sshd.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | haute |
| CIS | 5.1.2, 5.1.4 | direct | per OS, see the benchmark table | 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.