Introduction
La commande "su" (substitute user) sous Linux est un outil puissant qui permet aux utilisateurs de basculer temporairement vers un autre compte utilisateur, souvent l'utilisateur root, pour effectuer des tâches administratives. Cependant, des échecs d'authentification peuvent survenir, entraînant des refus d'accès et des risques de sécurité potentiels. Ce tutoriel vous guidera tout au long du processus de dépannage des échecs d'authentification su sous Linux, en abordant les causes courantes, les paramètres de configuration et les meilleures pratiques pour une utilisation sécurisée de su.
Comprendre la commande Su et son utilisation de base
Dans cette étape, vous apprendrez comment la commande su sous Linux permet aux utilisateurs de changer leur identité actuelle pour celle d'un autre utilisateur. Cela est particulièrement utile pour effectuer des tâches administratives nécessitant des privilèges élevés.
Explorons l'utilisation de base de la commande su et comprenons son fonctionnement.
Utilisation de base de Su
Ouvrez un terminal dans votre environnement de machine virtuelle LabEx. Vous pouvez utiliser la commande su avec la syntaxe suivante :
su [options] [username]
Si vous exécutez su sans spécifier de nom d'utilisateur, il bascule par défaut vers l'utilisateur root :
su
La commande cible root, mais Ubuntu verrouille normalement l’authentification de root par mot de passe. Un échec d’authentification est donc attendu ici. N’activez pas la connexion root par mot de passe et ne modifiez pas le compte de la plateforme ; tous les tests de connexion réussie ci-dessous utilisent des utilisateurs temporaires de cet exercice.
Créons un utilisateur de test pour nous entraîner :
sudo adduser testuser
Saisissez les informations demandées. Pour ce compte de test temporaire uniquement, utilisez DemoUser123! comme mot de passe d’entraînement. Ne modifiez jamais le mot de passe de labex ni son appartenance au groupe sudo.
Maintenant, essayons de basculer vers cet utilisateur :
su testuser
Lorsque vous y êtes invité, entrez le mot de passe que vous avez créé pour testuser. Une fois authentifié, votre invite de commande changera, indiquant que vous opérez désormais en tant que testuser.
Pour vérifier que vous avez réussi à changer d'utilisateur, exécutez :
whoami
La sortie devrait afficher :
testuser
Pour revenir à votre utilisateur d'origine, tapez simplement :
exit
Utilisation de Su avec des options
La commande su prend en charge plusieurs options. La plus courante est l'option - (tiret), qui fournit un environnement de connexion complet :
su - testuser
Cela ne change pas seulement l'identité de l'utilisateur, mais également :
- Change vers le répertoire personnel de l'utilisateur cible
- Configure les variables d'environnement de l'utilisateur cible
- Fournit un shell de connexion
Essayez cette commande et observez les différences :
pwd
La sortie devrait afficher le répertoire personnel de testuser :
/home/testuser
Quittez testuser en tapant :
exit
Cette compréhension de base de la commande su nous aidera à dépanner les échecs d'authentification dans les étapes suivantes.
Échecs d'authentification Su courants et leurs causes
Dans cette étape, vous allez créer et inspecter des échecs d'authentification su courants. Comprendre ces échecs est la première étape pour les résoudre.
Tester les échecs d'authentification
Créons intentionnellement quelques échecs d'authentification pour mieux les comprendre.
Tout d'abord, essayez de basculer vers testuser avec un mot de passe incorrect :
su testuser
Entrez un mot de passe incorrect. Vous verrez un message d'erreur similaire à :
su: Authentication failure
Ensuite, essayez de basculer vers un utilisateur inexistant :
su nonexistentuser
Vous verrez un message d'erreur comme :
su: user nonexistentuser does not exist
Causes courantes des échecs d'authentification
1. Mot de passe incorrect
La cause la plus fréquente d'échec d'authentification est simplement la saisie d'un mauvais mot de passe. Cela peut arriver à cause de :
- Fautes de frappe
- Verrouillage des majuscules activé
- Oubli du mot de passe
2. Restrictions de compte
Certains comptes peuvent être configurés pour empêcher la connexion ou avoir des mots de passe expirés :
Modifions notre utilisateur de test pour démontrer cela :
sudo usermod -L testuser
L’option -L verrouille l’authentification par mot de passe du compte temporaire testuser. Essayez maintenant :
su testuser
Vous verrez un échec d'authentification même si vous entrez le bon mot de passe.
L’option -U supprime ce verrouillage du mot de passe. Déverrouillez uniquement ce compte de test avec :
sudo usermod -U testuser
3. Problèmes de configuration PAM
Le système PAM (Pluggable Authentication Modules) contrôle l'authentification sous Linux. Des problèmes avec la configuration PAM peuvent provoquer des échecs de su.
Examinons la configuration PAM pour la commande su :
cat /etc/pam.d/su
Ce fichier contient la configuration PAM spécifique à la commande su. Recherchez les lignes susceptibles de restreindre l'accès, telles que :
auth required pam_wheel.so
Cette ligne, si elle est décommentée, restreindrait l'accès su aux membres du groupe wheel.
4. Problèmes de permissions avec le binaire Su
Le fichier binaire de la commande su doit avoir les bonnes permissions pour fonctionner correctement :
ls -l $(which su)
La sortie devrait afficher quelque chose comme :
-rwsr-xr-x 1 root root 71816 Apr 18 2022 /usr/bin/su
Le s dans les permissions indique que le bit setuid est défini, permettant au programme de s'exécuter avec les privilèges de son propriétaire (root) plutôt que de l'utilisateur qui l'exécute.
5. Examen des journaux d'authentification
Lors du dépannage des échecs d'authentification dans cette machine virtuelle LabEx, vérifiez les enregistrements de connexion échoués avec lastb :
sudo lastb | head
Cette commande lit /var/log/btmp et affiche les tentatives d'authentification échouées récentes, y compris les tentatives su échouées lorsqu'elles sont enregistrées par le système.
Par exemple, une tentative su échouée peut afficher une entrée incluant l'utilisateur cible et la session de terminal.
Comprendre ces causes courantes d'échecs d'authentification su vous aidera à identifier et à résoudre les problèmes plus efficacement dans les étapes suivantes.
Configuration du contrôle d'accès pour la commande Su
Dans cette étape, vous allez tester une règle de groupe PAM sur un compte cible temporaire. Vous n’activerez pas la connexion root par mot de passe et ne restreindrez pas l’accès à la plateforme.
Préparer les comptes temporaires
Commencez dans votre shell labex d’origine. Confirmez l’identité actuelle avant d’utiliser sudo :
whoami
Le résultat doit être labex. Créez un second utilisateur appelant et une cible distincte, puis définissez des mots de passe uniquement pour ces comptes temporaires :
sudo adduser --disabled-password --gecos '' testuser2
sudo adduser --disabled-password --gecos '' su-lab-target
printf '%s\n' 'testuser2:DemoOther123!' 'su-lab-target:DemoTarget123!' | sudo chpasswd
sudo groupadd sugroup
sudo usermod -aG sugroup testuser
Seul testuser est membre de sugroup. Les nouveaux shells de connexion prendront en compte cette appartenance. Le mot de passe de la cible est DemoTarget123! pour les deux tests d’appelants.
Appliquer une règle PAM spécifique à la cible
PAM contrôle l’authentification de su via /etc/pam.d/su. La préparation a sauvegardé ses octets d’origine sous /opt/labex/su-demo. Le préfixe géré suivant applique une vérification de groupe uniquement lorsque la cible est su-lab-target. La première règle ignore la règle suivante pour toutes les autres cibles, y compris labex. use_uid vérifie l’identité réelle de l’appelant, et group=sugroup désigne le groupe autorisé.
sudo python3 - <<'PY'
from pathlib import Path
original = Path('/opt/labex/su-demo/pam-su.original').read_text()
prefix = """## Lab-only rule for su-lab-target
auth [success=1 default=ignore] pam_succeed_if.so quiet user != su-lab-target
auth required pam_wheel.so use_uid group=sugroup
"""
Path('/etc/pam.d/su').write_text(prefix + original)
PY
Les règles PAM d’origine restent présentes après ce préfixe. L’appartenance au groupe ne remplace pas l’authentification par mot de passe. N’ajoutez pas labex au groupe de démonstration et ne modifiez aucune configuration SSH, sudo ou du compte de la plateforme.
Tester un appelant extérieur au groupe
Depuis labex, passez à testuser2 avec DemoOther123! :
su - testuser2
Depuis ce shell, tentez d’accéder à la cible concernée par la règle en utilisant son mot de passe correct DemoTarget123! :
su - su-lab-target
Cette tentative doit échouer avec une erreur d’authentification, car testuser2 n’appartient pas à sugroup. Un échec de su ne crée pas de nouveau shell. Quittez une seule fois pour revenir à labex :
exit
whoami
Confirmez que whoami affiche labex avant de continuer.
Tester un appelant membre du groupe
Passez à testuser avec son mot de passe DemoUser123! défini à l’étape 1 :
su - testuser
id
su - su-lab-target
Saisissez DemoTarget123! pour la cible. Ce changement d’utilisateur doit réussir. Confirmez l’identité cible :
whoami
La sortie doit être su-lab-target. Deux shells ont été ouverts ; quittez donc deux fois : d’abord pour revenir à testuser, puis à labex :
exit
exit
whoami
Confirmez que whoami affiche labex. N’exécutez jamais la commande de restauration depuis le shell d’un utilisateur temporaire.
Restaurer la politique d’origine
Depuis labex, restaurez la configuration sauvegardée et comparez-la à l’original :
sudo cp -p /opt/labex/su-demo/pam-su.original /etc/pam.d/su
sudo cmp /opt/labex/su-demo/pam-su.original /etc/pam.d/su
Une comparaison réussie n’affiche rien. Le groupe et les utilisateurs de démonstration restent disponibles pour le diagnostic, tandis que su utilise de nouveau sa politique d’origine.
Dépannage et résolution des échecs d'authentification Su
Dans cette étape, vous utiliserez un processus systématique pour dépanner et résoudre les échecs d’authentification su.
Diagnostiquer les échecs d’authentification
Lorsque vous rencontrez un échec d’authentification su, suivez ces étapes systématiques pour diagnostiquer le problème :
Étape 1 : Vérifier le message d’erreur
Le message d’erreur peut fournir des indices précieux sur la nature de l’échec. Les messages d’erreur courants incluent :
su: Authentication failure- Indique généralement un mot de passe incorrect.su: user username does not exist- Le compte utilisateur spécifié n’existe pas.su: permission denied- Des restrictions de contrôle d’accès empêchent l’opération.
Étape 2 : Vérifier le compte utilisateur
Assurez-vous que le compte utilisateur cible existe et n’est pas verrouillé :
grep testuser /etc/passwd
Cette commande doit afficher l’entrée de testuser dans le fichier des comptes, confirmant que le compte existe.
Vérifiez si le compte est verrouillé :
sudo getent shadow testuser | cut -d: -f2 | cut -c1
Cette commande n’affiche que le premier caractère du champ de mot de passe du compte temporaire, et non le hachage du mot de passe. Un ! initial signifie que l’authentification par mot de passe est verrouillée.
Étape 3 : Vérifier les restrictions de contrôle d’accès
Comme nous l’avons vu à l’étape précédente, la configuration PAM peut restreindre l’accès su. Recherchez ces restrictions :
grep -v "^#" /etc/pam.d/su | grep pam_wheel
Si cette commande renvoie une ligne contenant pam_wheel.so, l’accès à su peut être limité aux membres d’un groupe spécifique.
Étape 4 : Examiner les journaux système
Les enregistrements de connexion échoués peuvent fournir des informations utiles sur les échecs d’authentification :
sudo lastb | head
Recherchez les entrées liées à vos tentatives su échouées pour obtenir davantage de contexte.
Résoudre les échecs d’authentification Su courants
Abordons maintenant les échecs d’authentification su courants et leur résolution :
1. Mot de passe incorrect
Si vous saisissez le bon mot de passe mais obtenez toujours des échecs d’authentification, une réinitialisation du mot de passe peut être nécessaire :
printf '%s\n' 'testuser:DemoUser123!' | sudo chpasswd
Cette commande réinitialise uniquement le mot de passe du compte temporaire testuser à la valeur d’entraînement connue ; elle ne modifie ni labex ni root.
2. Compte verrouillé
Si le compte est verrouillé, déverrouillez-le :
sudo usermod -U testuser
3. Restrictions de contrôle d’accès
Si des restrictions de contrôle d’accès empêchent l’accès su, vous pouvez soit :
a. Ajouter l’utilisateur au groupe requis :
sudo usermod -aG sugroup testuser2
Cette commande ajoute testuser2 à sugroup.
b. Pour cet exercice, supprimer uniquement la politique de démonstration en restaurant le fichier d’origine sauvegardé :
sudo cp -p /opt/labex/su-demo/pam-su.original /etc/pam.d/su
Cette commande restaure exactement la politique su d’origine au lieu de désactiver arbitrairement des règles d’authentification.
4. Problèmes de permissions de fichier
Inspectez les permissions du binaire su sans modifier le binaire de la plateforme :
ls -l "$(command -v su)"
Le bit setuid attendu apparaît sous la forme s à la position d’exécution du propriétaire. Si le binaire de la plateforme est endommagé, utilisez une nouvelle VM plutôt que de modifier ses permissions.
Tester les correctifs
Après avoir appliqué les correctifs, vérifiez que l’authentification su fonctionne correctement :
su - testuser
Saisissez le mot de passe de testuser lorsque cela vous est demandé. En cas de réussite, vous devez maintenant être connecté en tant que testuser.
Exécutez whoami pour confirmer testuser, puis exit une seule fois pour revenir à labex. N’utilisez pas la connexion root par mot de passe comme test de réussite : la connexion au compte temporaire constitue le cas positif.
Ces étapes de dépannage et ces correctifs traitent les échecs d’authentification su les plus courants. En diagnostiquant et en résolvant systématiquement ces problèmes, vous pouvez vous assurer que la commande su fonctionne correctement sur votre système.
Meilleures pratiques pour une utilisation sécurisée de Su
Dans cette étape, vous allez examiner l’utilisation sûre des privilèges et confirmer que la démonstration a laissé l’accès à la plateforme inchangé.
Préférer Sudo pour les commandes administratives individuelles
Sudo permet d’autoriser et de journaliser des actions administratives individuelles sans partager le mot de passe root. Depuis votre shell labex, listez le répertoire personnel de root sans démarrer de shell de connexion root :
sudo ls /root
Conservez la politique sudo existante de la plateforme. Vous pouvez examiner les commandes qui vous sont autorisées sans modifier cette politique :
sudo -l
Limiter la portée des changements d’authentification
Sur les systèmes de production, les administrateurs gèrent la connexion root, la qualité des mots de passe et la politique d’authentification au moyen de procédures de configuration approuvées. Cet exercice ne modifie ni les paramètres SSH, ni le mot de passe de labex, ni l’appartenance de labex aux groupes. Une politique de mot de passe robuste ou une authentification multifacteur nécessite sa propre mise en œuvre ; aucune des deux n’est configurée par ce tutoriel.
Confirmez que la politique su temporaire a été supprimée :
sudo cmp /opt/labex/su-demo/pam-su.original /etc/pam.d/su
L’absence de sortie signifie que la politique correspond à l’original sauvegardé.
Auditer les tentatives d’authentification échouées
Utilisez la base de données des connexions échouées pour examiner les tentatives infructueuses :
sudo lastb | head
Cette commande lit /var/log/btmp ; elle n’affiche pas toutes les sessions su réussies. Interprétez uniquement les enregistrements réellement écrits par le système et enquêtez sur les échecs répétés dans un environnement de production.
Utiliser un environnement de connexion et revenir explicitement
L’option tiret démarre l’environnement de connexion de l’utilisateur cible. Utilisez le mot de passe DemoUser123! de testuser :
su - testuser
whoami
exit
whoami
Les deux vérifications d’identité doivent afficher testuser, puis labex. La commande exit ferme uniquement le shell créé par su. La VM conserve sa connexion à la plateforme, son accès sudo et sa politique su d’origine.
Résumé
Dans ce laboratoire, nous avons exploré la commande su sous Linux et appris à dépanner les échecs d'authentification courants. Nous avons couvert :
- La compréhension de l'utilisation de base de la commande
suet son fonctionnement - L'identification des causes courantes des échecs d'authentification su, notamment les mots de passe incorrects, les restrictions de compte et les problèmes de configuration PAM
- La configuration du contrôle d'accès pour la commande
suafin d'améliorer la sécurité - Le dépannage et la résolution des échecs d'authentification su par un diagnostic systématique
- La mise en œuvre des meilleures pratiques pour une utilisation sécurisée de su, notamment l'utilisation de sudo lorsque cela est possible, la configuration de politiques de mot de passe robustes et l'audit régulier de l'utilisation de su
En appliquant ces techniques et meilleures pratiques, vous pouvez vous assurer que la commande su fonctionne correctement tout en maintenant la sécurité de votre système Linux. N'oubliez pas qu'une gestion appropriée de l'authentification est un aspect crucial de l'administration système et de la sécurité.
