Désactiver l'authentification Kerberos
Force KerberosAuthentication no afin que SSH ne propose pas la validation directe de mot de passe Kerberos comme méthode d'authentification.
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
L'authentification Kerberos pour SSH (souvent implémentée au-dessus de GSSAPI) expose l'implémentation Kerberos du système aux clients distants. Sur un hôte ne faisant pas partie d'un domaine Kerberos, c'est un chemin d'authentification inutilisé qui ne fait qu'élargir la surface d'attaque. La désactiver garantit que le démon SSH ne se rabat pas sur des méthodes d'authentification inutilisées, même si une mauvaise configuration ailleurs les activerait.
Ce que vérifie Pavois
Pavois lit la valeur effective via sshd -T, résolue après tous les Include, drop-ins de /etc/ssh/sshd_config.d/ et blocs Match (y compris les includes de politique crypto RHEL). Une lecture de /etc/ssh/sshd_config ne révélerait pas un KerberosAuthentication yes posé dans un fragment inclus.
describe command('sshd -T') do
its('stdout') { should match(/^kerberosauthentication\s+no$/i) }
endComment vérifier qu’elle est appliquée
Exécutez sshd -T | grep -i '^kerberosauthentication'. La sortie attendue est kerberosauthentication no.
Inspecter et investiguer
La négociation et les échecs d'authentification sont journalisés via journalctl -u sshd (famille RHEL) ou dans /var/log/secure ; utilisez LogLevel VERBOSE pour la méthode proposée à chaque connexion.
Remédiation
Le plan harden de Pavois écrit la directive sshd_setting KerberosAuthentication no dans un drop-in géré, valide avec sshd -t, puis recharge le service ssh. Appliquez-le avec pavois harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| directive | kerberosauthentication |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | no |
| verify | sshd -t -f %{path} |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Avant d'appliquer, vérifiez que l'hôte n'est pas joint à Kerberos/AD et qu'aucun utilisateur ne s'authentifie via des mots de passe adossés à Kerberos en SSH. Sur un hôte autonome, aucun impact. Si l'authentification unique Kerberos est requise, laissez cette option activée et appuyez-vous sur d'autres durcissements. Le rechargement préserve les sessions actives.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| NIST | 3.1.12 | 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.