Limiter l'accès SSH des utilisateurs
Exige que sshd définisse une liste d'accès explicite, au moins l'une de AllowUsers, AllowGroups, DenyUsers ou DenyGroups, afin que seuls les comptes approuvés puissent se connecter en SSH.
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
Par défaut, tout compte local disposant d'un mot de passe ou d'une clé valide peut se connecter en SSH, y compris les comptes de service ou hérités qui ne devraient jamais avoir d'accès shell distant. Lister explicitement les quelques comptes (ou groupes) nécessitant SSH, ou interdire ceux qui ne doivent pas l'utiliser, réduit la surface d'attaque distante et limite l'impact d'un identifiant compromis, en appliquant le moindre privilège au point d'entrée réseau.
Ce que vérifie Pavois
Pavois lit la configuration sshd effective avec sshd -T, qui affiche les directives entièrement résolues après l'analyse de sshd_config, de chaque Include (par ex. /etc/ssh/sshd_config.d/*.conf) et des valeurs par défaut des blocs Match. Un examen basé sur le seul fichier sshd_config manquerait les directives placées dans les drop-ins ou les blocs Match, donnant un faux négatif ; sshd -T reflète ce que le démon applique réellement.
describe command('sshd -T 2>/dev/null | grep -qiE \'^(allowusers|allowgroups|denyusers|denygroups) .\' && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Exécutez sshd -T | grep -iE '^(allowusers|allowgroups|denyusers|denygroups) '. La sortie attendue est au moins une telle ligne avec une valeur non vide, par ex. allowgroups ssh-users.
Inspecter et investiguer
Les décisions d'authentification et d'accès SSH sont journalisées dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL), et via journalctl -u ssh / journalctl -u sshd. Un utilisateur bloqué par ces listes apparaît sous la forme User <name> ... not allowed because ... dans ces journaux.
Remédiation
Aucun plan de durcissement automatisé n'est défini ; cela doit donc être appliqué manuellement : ajoutez une directive AllowGroups/AllowUsers (ou DenyGroups/DenyUsers), idéalement dans un drop-in tel que /etc/ssh/sshd_config.d/10-access.conf, listant les comptes ou groupes approuvés, validez avec sshd -t, puis rechargez avec systemctl reload ssh.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | # Decide the allowed users/groups, then add to /etc/ssh/sshd_config.d/ a drop-in, e.g.: # AllowGroups ssh-users # and: systemctl reload ssh |
|---|---|
| reason | which users/groups may SSH is SITE-SPECIFIC, pavois cannot guess it |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
C'est le changement SSH le plus risqué pour un verrouillage : une liste AllowUsers/AllowGroups omettant votre propre compte refusera votre prochaine connexion, et sshd ne ferme pas rétroactivement les sessions existantes. Incluez toujours votre compte/groupe d'administration, validez la configuration avec sshd -t, rechargez (ne stoppez pas) sshd, et confirmez une nouvelle connexion dans une seconde session avant de fermer la première. Les comptes de service utilisant légitimement SSH (sauvegardes, CI) doivent aussi être inclus.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 2.2.6, 5.1.4, 5.1.7, 5.1.6 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.12, AC-3, CM-6(a) | 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.