sudo, su et su - sous Linux sans confusion

La différence entre sudo, su et su - ne se résume pas à “passer root”. Ces commandes ne changent pas seulement les droits disponibles : elles changent aussi la façon d’authentifier l’utilisateur, l’environnement chargé, la traçabilité et le risque d’erreur. C’est exactement pour cela qu’un bon administrateur ne choisit pas la commande la plus rapide, mais celle qui correspond au contexte, à l’équipe et au niveau de preuve attendu concrètement.

Sur un poste Linux comme sur un serveur, le bon réflexe est de choisir le niveau d’élévation minimal. Une commande d’administration ponctuelle ne demande pas forcément une session root complète. À l’inverse, certaines opérations de maintenance exigent un environnement propre du compte cible.

Ce guide reprend les bases de manière opérationnelle : quand utiliser chaque commande, ce que change réellement le tiret de su -, et pourquoi sudo -i est souvent plus lisible que le vieux réflexe sudo su.

Sudo, su et su - : la différence en une phrase utile

sudo exécute une commande avec les droits prévus par la politique sudoers. su ouvre une session sous un autre utilisateur en demandant le mot de passe de ce compte. su - fait la même bascule, mais comme une session de connexion complète, avec l’environnement du compte cible.

Cette distinction paraît théorique jusqu’au premier incident : un script qui ne trouve pas le bon binaire, une variable HOME incohérente, un fichier créé root dans un dossier utilisateur, ou une action impossible à rattacher clairement à la personne qui l’a déclenchée. Dans ces moments-là, le détail de session devient une information de diagnostic, pas une subtilité de manuel que l’on peut ignorer longtemps. Le choix de la commande devient alors un outil de diagnostic.

Quand sudo est le meilleur choix

sudo est conçu pour déléguer une action précise. L’utilisateur tape par exemple sudo systemctl restart nginx, le système vérifie la politique configurée, demande une authentification si nécessaire, puis exécute la commande avec les privilèges autorisés. Cette logique convient bien aux tâches où l’on veut élever un geste, pas changer toute l’identité de travail.

La nuance importante est l’identité utilisée pour interroger la politique : sudo s’appuie sur l’utilisateur appelant. Vous ne donnez pas le mot de passe root à chaque administrateur ; vous autorisez certains utilisateurs ou groupes à exécuter certaines commandes. Cette nuance suffit souvent à séparer une administration propre d’un simple partage de secret root entre plusieurs personnes.

C’est pour cela que sudo convient bien aux environnements d’équipe. Il permet une délégation fine, une révocation plus simple et une meilleure lecture des journaux. Un administrateur junior peut recevoir le droit de redémarrer un service sans obtenir une session root permanente.

La sécurité ne vient pas de la commande seule : elle vient de la règle précise qui l’encadre.

Dans une PME, cette granularité évite un dilemme très courant : soit tout le monde attend l’administrateur principal, soit trop de personnes disposent d’un accès root complet. sudo permet une troisième voie plus saine. On délègue une opération opérationnelle, par exemple relancer un service ou consulter certains journaux, tout en conservant une barrière claire entre l’exploitation courante et l’administration complète du système, y compris lors d’un remplacement temporaire non planifié urgent.

• Pour une commande unique, commencez par sudo commande.
• Pour vérifier vos droits, utilisez sudo -l.
• Pour invalider le cache d’authentification, utilisez sudo -k.
• Pour éditer un fichier système, préférez sudoedit lorsque c’est adapté.

Ce que su change vraiment

La commande su signifie “substitute user” dans son usage moderne : elle permet de lancer un shell ou une commande avec l’identité d’un autre utilisateur. Sans nom d’utilisateur, elle vise généralement root. Contrairement à sudo, elle demande le mot de passe de l’utilisateur cible. Cette différence déplace donc le centre de gravité : on ne valide plus un droit délégué, on prouve l’accès au compte visé lui-même directement, localement, explicitement.

Ce comportement a une conséquence forte. Si plusieurs personnes connaissent le mot de passe root, il devient plus difficile de rattacher chaque action à une personne précise. On peut journaliser l’ouverture de session, mais la granularité des commandes exécutées ensuite dépend de la configuration du système et des journaux shell. Ce n’est pas un détail d’école lorsque plusieurs prestataires ou administrateurs interviennent sur le même serveur.

su reste utile dans des cas concrets : tester un compte applicatif, vérifier un environnement utilisateur, reproduire un bug lié aux droits, ou effectuer une courte séquence où l’on doit réellement devenir un autre compte. Le problème commence quand su vers root devient une habitude pour toute action administrative.

Un autre point souvent oublié : su ne charge pas forcément un environnement de connexion complet. Il peut conserver une partie du contexte précédent, ce qui suffit à créer des comportements déroutants sur les chemins, les alias ou les variables.

Pour approfondir ce point, consultez Maîtriser la commande mv sous Linux :, qui traite plus précisément de maîtriser la commande mv sous linux : guide pratique et exemples concrets.

Dans les petites équipes, ce flou passe parfois inaperçu parce que tout le monde “sait” qui a touché au serveur. Cette mémoire informelle disparaît dès qu’un incident survient, qu’un prestataire quitte le projet ou qu’une modification doit être auditée plusieurs semaines plus tard. Une commande claire et un compte nominatif valent mieux qu’une habitude rapide mais impossible à relire après coup, même avec un historique complet centralisé. La simplicité apparente de su doit donc rester encadrée.

Pourquoi le tiret de su - compte autant

su -, équivalent pratique de su --login, demande une session de connexion du compte cible. La documentation util-linux indique notamment que cette option nettoie largement l’environnement, initialise HOME, SHELL, USER, LOGNAME et PATH, puis bascule vers le répertoire personnel du compte cible. C’est ce comportement qui rend la commande utile quand l’environnement influence réellement le résultat ou la reproductibilité d’un test serveur fiable.

Autrement dit, su répond surtout à “je veux changer d’identité”, tandis que su - répond à “je veux travailler comme si je m’étais connecté sous ce compte”. Ce détail explique beaucoup d’écarts entre un test rapide et un comportement réel en production.

Le cas des comptes applicatifs illustre bien le problème. Un service peut dépendre d’un PATH particulier, d’un fichier de profil, d’une variable de langue ou d’un répertoire personnel spécifique. Si vous testez avec une session qui conserve trop de traces de votre utilisateur courant, vous pouvez conclure à tort que l’application fonctionne ou, au contraire, poursuivre une erreur qui n’existe pas dans le contexte réel du service en production réelle applicative.

Sur un serveur, ce choix devient pratique. Si un script doit utiliser les variables du compte postgres, www-data ou d’un utilisateur applicatif, une session incomplète peut masquer le vrai problème. Dans ce cas, l’environnement complet vaut mieux qu’une demi-bascule.

À l’inverse, ouvrir une session login root pour une seule commande est souvent excessif. Vous augmentez la surface d’erreur : un mauvais dossier, une suppression trop large, une redirection mal placée, et la commande s’exécute avec tous les droits. Le tiret n’est donc pas cosmétique : il décrit une intention de session complète, pas seulement une variante typographique.

Sudo -i, sudo -s et le piège de sudo su

sudo su est devenu un raccourci courant : sudo autorise l’exécution de su, puis su ouvre une session root. Cela fonctionne souvent, mais l’intention est moins nette. Voulez-vous tester su ? Ouvrir un shell root ? Charger un environnement complet ? Utiliser la politique sudo ? Tout est mélangé. Cette ambiguïté gêne les procédures, les audits et la formation des nouveaux administrateurs système.

sudo -i exprime mieux le besoin d’un shell de connexion via sudo. La documentation sudo décrit l’option -i comme l’exécution du shell du compte cible en mode login, avec lecture des fichiers de profil et tentative de changement vers son répertoire personnel.

sudo -s, lui, lance un shell en utilisant le shell de l’utilisateur appelant ou celui défini dans la base des comptes. Il peut être utile pour une session interactive courte, mais il ne porte pas le même message que sudo -i.

En production, une commande lisible est aussi une forme de documentation opérationnelle pour l’équipe qui reprend l’incident.

La règle pragmatique est simple : si vous avez besoin d’un shell root encadré par sudo, utilisez sudo -i. Si vous avez besoin d’une seule commande, restez sur sudo. Si vous devez devenir un autre utilisateur avec son mot de passe et son environnement, choisissez su ou su - explicitement. Ce vocabulaire commun réduit les ambiguïtés dans les consignes.

Exemples concrets sur un serveur Linux

Imaginez une mise à jour de configuration Nginx. Vous modifiez un fichier, vérifiez la syntaxe, puis rechargez le service. Dans ce cas, sudo suffit largement : sudo nginx -t, puis sudo systemctl reload nginx. Vous n’avez pas besoin d’un shell root qui resterait ouvert pendant toute la session SSH. La séquence reste courte, vérifiable et facile à relire dans un journal d’intervention. La commande doit rester proportionnée au changement réellement prévu, surtout sur une machine exposée publiquement.

Pour un compte applicatif, la logique change. Si vous devez comprendre pourquoi une tâche cron lancée par deploy ne trouve pas le même binaire que dans votre shell, le sujet n’est pas seulement le droit d’exécuter une commande. Il faut reproduire l’environnement de deploy, son répertoire, son PATH, parfois ses fichiers de profil. Dans ce cas, su - deploy ou un équivalent contrôlé devient plus cohérent qu’un empilement de sudo.

Autre scénario : une intervention de récupération après incident. Vous devez vérifier plusieurs fichiers système, corriger une permission, relancer un service et consulter les journaux. Une session sudo -i peut se défendre, à condition de noter l’intervention, de limiter la durée et de fermer le shell dès que le diagnostic est terminé.

Le point commun de ces exemples est la durée. Plus une opération est courte et ciblée, plus sudo est naturel. Plus elle dépend de l’environnement complet d’un compte, plus une vraie bascule de session se justifie. Plus elle touche à plusieurs couches du système, plus la préparation, la traçabilité et la sortie de session deviennent importantes. La commande n’est qu’un indicateur de cette décision, pas une fin en soi dans le runbook. Le mauvais signe, c’est l’habitude qui remplace l’analyse du besoin réel.

Si la première commande tapée après chaque connexion SSH est systématiquement sudo su, la politique d’accès mérite une revue. Soit les droits sudo sont trop mal découpés pour permettre les actions courantes, soit les administrateurs contournent le modèle de délégation au lieu de l’améliorer. Dans les deux cas, le problème est organisationnel autant que technique.

Pour approfondir ce point, consultez Sudo sous Linux, méthode fiable pour administrer, qui traite plus précisément de sudo sous linux, méthode fiable pour administrer sans ouvrir la porte root.

Un bon runbook peut même imposer la commande attendue pour chaque opération récurrente. Ce détail réduit les écarts entre administrateurs, facilite les revues après incident et évite que chacun choisisse son raccourci préféré sous pression. La standardisation n’empêche pas l’expertise ; elle protège surtout les gestes répétitifs, ceux qui finissent par créer les incidents les plus évitables en exploitation quotidienne réelle partagée ensuite. Une procédure claire vaut mieux qu’un raccourci mémorisé.

Les erreurs fréquentes avec les privilèges root

La première erreur est de lancer une session root “pour gagner du temps”. Plus la session dure, plus une commande banale peut produire un effet disproportionné. C’est particulièrement vrai avec les opérations récursives, les redirections shell et les chemins relatifs. Une session root ouverte depuis dix minutes finit par banaliser un niveau de risque qui devrait rester exceptionnel.

La deuxième erreur est de modifier /etc/sudoers directement avec un éditeur classique. Une faute de syntaxe peut bloquer sudo. L’outil visudo existe précisément pour valider le fichier avant de l’enregistrer et éviter ce type d’incident.

La troisième erreur est de confondre authentification et autorisation. Saisir un mot de passe ne veut pas dire que la règle est saine. Un compte peut être autorisé trop largement, par exemple avec un accès global à ALL, alors qu’un périmètre de commandes suffirait.

Enfin, évitez de copier des commandes d’Internet avec sudo sans les lire. Une option inoffensive dans un tutoriel peut devenir destructrice dans votre arborescence, surtout si elle combine rm, chown, chmod, jokers ou redirections. La prudence commence avant la touche Entrée.

Le cas le plus dangereux n’est pas toujours la commande spectaculaire. Une redirection avec sudo mal comprise peut écrire dans un fichier système inattendu ; un chown -R lancé depuis le mauvais dossier peut casser une application ; un joker trop large peut toucher plus de fichiers que prévu. Avant d’élever les privilèges, relisez le chemin, le répertoire courant et l’effet exact de chaque option, surtout en SSH distant ouvert.

Mettre en place une politique sudo propre

Une politique propre commence par les groupes. Sur beaucoup de distributions, l’accès sudo passe par un groupe administrateur, mais ce n’est qu’un point de départ. Pour un serveur, il vaut mieux définir qui peut faire quoi, sur quelle machine et avec quel niveau de privilège. Cette précision simplifie aussi les audits, car la règle décrit l’usage attendu au lieu d’accorder un accès illimité.

Dans un fichier sudoers ou un fichier sous /etc/sudoers.d/, la délégation peut s’appuyer sur des alias d’utilisateurs, de groupes, d’hôtes et de commandes. Cette granularité permet d’éviter deux extrêmes : donner root à tout le monde ou bloquer des opérations simples qui devraient être autonomes. La règle doit rester lisible six mois plus tard, y compris par une personne qui n’a pas écrit la configuration.

1. Créer des groupes selon les rôles réels : exploitation, sauvegarde, déploiement, support.
2. Limiter les commandes autorisées à des chemins absolus lorsque c’est possible.
3. Documenter pourquoi une règle existe et qui la valide.
4. Revoir régulièrement les droits des anciens comptes et prestataires.
5. Tester les règles avec sudo -l -U utilisateur depuis un compte administrateur autorisé.

Pour les machines sensibles, ajoutez une logique de journalisation et de revue. L’intérêt de sudo est aussi organisationnel : l’audit des actions administratives devient exploitable si les comptes sont nominatifs et les règles cohérentes.

Cette approche prend un peu plus de temps au départ, mais elle réduit les exceptions permanentes. Au lieu d’ajouter un accès root global à chaque blocage, l’équipe enrichit progressivement une politique sudo compréhensible. Les droits deviennent alors un inventaire maîtrisé, pas une collection de passe-droits accumulés au fil des urgences, des changements d’équipe et des migrations successives de l’infrastructure. Le vrai gain se voit lors des départs et des audits.

Quelle commande utiliser selon le contexte ?

Sur un poste personnel, la question est souvent simple : utilisez sudo pour installer, mettre à jour ou modifier un fichier système, puis revenez à votre utilisateur normal. Sur un serveur partagé, la réponse doit être plus structurée, car l’enjeu n’est pas seulement technique mais aussi opérationnel. Chaque session élevée doit pouvoir être comprise par l’équipe qui maintiendra la machine après vous demain matin, sans ambiguïté.

Pour un compte applicatif, su - utilisateur peut être pertinent afin de reproduire exactement l’environnement chargé au démarrage. Pour une tâche root ponctuelle, sudo garde l’action plus courte. Pour une intervention longue mais assumée, sudo -i rend l’intention plus claire qu’un empilement sudo su.

Le bon choix se repère à la question que vous vous posez. “Ai-je besoin d’une commande ?” mène vers sudo. “Ai-je besoin de devenir ce compte ?” mène vers su. “Ai-je besoin de son environnement complet ?” mène vers su -. “Ai-je besoin d’un shell root via la politique sudo ?” mène vers sudo -i. Cette grille évite les débats de préférence et ramène la discussion au besoin réel de l’opération.

Elle aide aussi à former les nouveaux administrateurs. Au lieu d’apprendre une suite de raccourcis, ils comprennent le modèle mental : commande, identité, environnement, journalisation. Ce modèle reste valable sur la plupart des distributions Linux, même si les groupes par défaut, les politiques PAM ou les chemins de journaux changent selon Debian, Ubuntu, Red Hat, AlmaLinux ou d’autres environnements serveur courants modernes actuels.

À retenir pour administrer sans multiplier les risques

La différence entre sudo, su et su - tient à trois critères : la délégation, l’identité de session et l’environnement chargé. Les confondre fonctionne parfois, mais ce flou finit par coûter cher quand un serveur, un script ou une équipe entre en jeu.

En pratique, partez de sudo pour les actions ciblées. Passez à su seulement lorsque vous devez réellement devenir un autre utilisateur. Utilisez su - lorsque l’environnement du compte cible est une partie du problème. Et si vous voulez une session root encadrée par sudo, préférez sudo -i à un réflexe historique difficile à expliquer.

Une bonne commande root est une commande dont on peut expliquer le besoin, le périmètre et la trace.

Pour approfondir ce point, consultez Ajouter un utilisateur sudo sous Linux sans, qui traite plus précisément de ajouter un utilisateur sudo sous linux sans ouvrir trop de droits.