Activer le service OpenSSH
Garantit que le service sshd.service (serveur OpenSSH) est activé au démarrage et en cours d'exécution, fournissant un canal d'administration distante chiffré et authentifié.
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
OpenSSH (sshd) fournit le canal d'administration distante chiffré et authentifié sur lequel s'appuient les administrateurs et l'automatisation. Contrairement aux protocoles hérités (telnet, rsh, FTP), SSH protège les identifiants et les données de session en transit, se défendant contre l'interception et l'altération sur des réseaux non fiables. Si sshd n'est ni activé ni en cours d'exécution, soit l'administration distante est impossible (risque opérationnel : aucune voie de récupération sur les serveurs sans écran), soit il a été remplacé par une alternative non sécurisée. Pour la plupart des serveurs, un démon SSH activé et fonctionnel est une exigence de base pour une administrabilité sûre, ce qui explique pourquoi NIST SC-8 et les STIG l'imposent.
Ce que vérifie Pavois
Pavois lit l'état effectif de sshd.service depuis systemd, en vérifiant qu'il est à la fois enabled (démarrera au boot) et running (actif maintenant). Cela détecte un démon installé mais masqué, ayant échoué à démarrer, ou seulement activé par socket sans jamais avoir été déclenché, précisément les conditions qui laisseraient silencieusement un serveur inadministrable. Une vérification de paquet ou de fichier de configuration signalerait le serveur SSH « présent » alors qu'il est en réalité arrêté.
describe service('sshd.service') do
it { should be_enabled }
it { should be_running }
endComment vérifier qu’elle est appliquée
Exécutez systemctl is-enabled sshd.service et systemctl is-active sshd.service ; attendez enabled et active. Confirmez qu'il accepte les connexions avec ss -tlnp | grep :22 et validez la configuration effective avec sshd -T | head (nécessite root).
Inspecter et investiguer
Les événements d'authentification et de session sont dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL) ; le démarrage/arrêt et les erreurs du démon sont dans journalctl -u sshd.service (ou ssh.service sur Debian/Ubuntu). systemctl show sshd.service -p ActiveState -p UnitFileState donne l'état que Pavois vérifie. Confirmez l'écoute avec ss -tlnp | grep :22.
Remédiation
Le plan de durcissement de Pavois agit sur la ressource service nommée sshd avec les actions enable puis start : il configure l'unité pour démarrer au boot et la lance immédiatement. Appliqué avec pavois harden apply. Remarque : sur Debian/Ubuntu l'unité est ssh.service avec un alias sshd.service.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| action | enable, start |
|---|---|
| name | sshd.service |
| resource | service |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Activer et démarrer sshd ouvre le port TCP 22 à la connexion distante ; cela doit donc s'accompagner d'une configuration SSH durcie : authentification par clé, PermitRootLogin no, pas d'authentification par mot de passe quand c'est possible, et un pare-feu hôte délimitant qui peut atteindre le port. Le risque opérationnel le plus important est l'inverse de cette règle, n'arrêtez ni ne désactivez jamais sshd sur un hôte distant/sans écran sans voie d'accès alternative (console, IPMI/iDRAC, console série cloud), sous peine de vous verrouiller dehors. Avant d'appliquer : assurez-vous de ne pas dépendre d'une session ouverte qu'un redémarrage pourrait couper, et que les règles de pare-feu autoriseront toujours votre réseau d'administration une fois sshd démarré.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| NIST | 3.1.13, CM-6(a), SC-8, SC-8(1), SC-8(2), SC-8(3), SC-8(4) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| DISA STIG | UBTU-22-255015, UBTU-24-100810 | direct | per OS STIG release | 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.