Sudo sans mot de passe pour une commande : sudoers et visudo

Pour autoriser sudo sans mot de passe pour une seule commande, créez un fichier dans /etc/sudoers.d avec visudo -f et ajoutez une règle telle que user ALL=(root) NOPASSWD: /chemin/absolu arguments. Le chemin absolu et les arguments fixes limitent la permission à cette commande exacte. NOPASSWD: ALL, en revanche, revient à distribuer root sans mot de passe.

Une règle sudoers NOPASSWD pour une commande : exemple complet avec visudo

La règle se crée avec visudo -f sur un nouveau fichier dans /etc/sudoers.d, jamais en ouvrant le fichier dans un éditeur quelconque. L'exemple utilise un utilisateur deploy qui doit seulement recharger nginx après une mise en production :

sudo visudo -f /etc/sudoers.d/deploy-nginx

Contenu du fichier :

# deploy may reload nginx without a password, and nothing else
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl reload nginx

Vérifiez d'abord le chemin avec command -v systemctl. Selon la distribution, il peut se trouver dans /usr/bin ou /bin, et la règle ne correspond qu'au chemin exact. Ensuite, validez et testez :

sudo visudo -c
sudo -l -U deploy
sudo -n /usr/bin/systemctl reload nginx

visudo -c vérifie la syntaxe de tous les fichiers sudoers. sudo -l -U deploy liste ce que cet utilisateur peut exécuter. sudo -n, lancé en tant que deploy, échoue au lieu de demander un mot de passe : il vous indique donc si NOPASSWD s'applique réellement.

Pourquoi utiliser visudo et /etc/sudoers.d au lieu de modifier /etc/sudoers à la main

visudo verrouille le fichier pendant que vous le modifiez et vérifie la syntaxe avant d'enregistrer. S'il trouve une erreur, il vous avertit et vous permet de la corriger. Un /etc/sudoers cassé peut rendre sudo inutilisable, et sur un serveur sans mot de passe root, cela signifie un passage par la console de récupération.

Un fichier par permission. Supprimer le fichier révoque la règle sans toucher à rien d'autre.
Séparé du fichier principal. Les modifications qu'un paquet apporte à /etc/sudoers n'entrent pas en conflit avec les vôtres.
Pas de points dans les noms de fichiers. sudo ignore les fichiers de /etc/sudoers.d dont le nom contient un point ou se termine par ~ : deploy-nginx est lu, deploy.conf ne l'est pas.
Propriété de root, mode 0440. Vérifiez avec ls -l /etc/sudoers.d ; si vous avez copié le fichier depuis ailleurs, corrigez-le avec chown root:root et chmod 0440.

Chemins absolus dans NOPASSWD : pourquoi sudoers les exige et comment fixer les arguments

sudoers exige le chemin complet de l'exécutable : un nom seul comme systemctl est une erreur de syntaxe dans visudo. Le chemin absolu empêche quiconque de déposer un autre binaire portant le même nom dans un répertoire de son PATH et de l'exécuter en tant que root.

Les arguments constituent l'autre moitié du contrôle :

Aucun argument dans la règle (/usr/bin/systemctl) : tous les arguments sont autorisés, y compris arrêter ou modifier n'importe quel service.
Arguments exacts (/usr/bin/systemctl reload nginx) : uniquement cette ligne de commande.
Un "" vide (/usr/local/bin/backup "") : la commande n'est acceptée que sans argument.
Jokers (/usr/bin/systemctl restart *) : l'astérisque correspond aussi aux espaces et laisse passer plus d'arguments que prévu. Évitez-les.

Pourquoi éviter NOPASSWD: ALL dans sudoers : comparaison des risques

Avec NOPASSWD: ALL, n'importe quel processus tournant sous votre utilisateur —un script compromis, une dépendance malveillante, une clé SSH volée— obtient root via sudo -n sans aucune interaction. Une règle restreinte réduit ce butin à une seule commande.

Ce qui est mesuré	Règle restreinte avec chemin absolu	NOPASSWD: ALL	sudo avec mot de passe
Portée sans mot de passe	Une ligne de commande exacte	N'importe quelle commande en root	Aucune
Adapté à l'automatisation	Oui, pour cette tâche	Oui, sans aucune limite	Non, `sudo -n` échoue
Si la session de l'utilisateur est volée	L'attaquant ne peut exécuter que cette commande	L'attaquant est root	L'attaquant a aussi besoin du mot de passe
Audit avec `sudo -l`	Affiche la commande autorisée	Affiche ALL, sans détail	Dépend des autres règles

Une règle restreinte reste dangereuse si la commande autorisée peut lancer un shell ou exécuter d'autres programmes : des éditeurs comme vi, des pagers comme less, find avec -exec, ou un script que l'utilisateur peut modifier. Si vous autorisez un script, il doit appartenir à root et n'être modifiable par personne d'autre. Pour modifier des fichiers protégés, utilisez sudoedit, qui travaille sur une copie avec les permissions de l'utilisateur. L'étiquette NOEXEC peut empêcher une commande d'en lancer d'autres, mais elle ne fonctionne pas avec tous les binaires.

Ordre des règles dans sudoers : la dernière correspondance l'emporte

Lorsque plusieurs règles correspondent au même utilisateur et à la même commande, sudo applique la dernière. Si /etc/sudoers.d est inclus à la fin de /etc/sudoers, votre règle NOPASSWD se place après la règle générale du groupe d'administration et prend le dessus. Si une ligne ultérieure exige un mot de passe pour cet utilisateur, elle annule votre règle et sudo -n continue d'échouer. sudo -l affiche les entrées dans l'ordre, ce qui permet de repérer facilement le conflit.

Modifier sudoers depuis votre téléphone avec termi1 sans vous bloquer l'accès

visudo ouvre l'éditeur configuré sur le système, souvent vi ou nano, et tous deux nécessitent Échap, Ctrl et les touches fléchées. Le clavier propre à termi1 dispose des touches que le clavier du système masque, ainsi que d'une couche fn avec F1–F12, PgUp/PgDn, Home et End.

Gardez un shell root de secours. Ouvrez sudo -i dans une autre fenêtre tmux avant de toucher à sudoers ; si quelque chose casse, vous avez encore root pour réparer.
Maintenez la session active. Avec Mosh, termi1 conserve la session lorsque vous passez du wifi aux données mobiles, et tmux garde tout ce que vous avez laissé en cours d'exécution.
Relisez avant d'exécuter. L'IA de termi1 transforme une phrase comme « laisser deploy recharger nginx sans mot de passe » en une commande saisie à l'invite sans appuyer sur Entrée. Sur les connexions marquées comme production, Production Guard retient tout ce qui supprime, arrête ou modifie quelque chose avant que cela n'atteigne l'invite.

Les clés SSH peuvent être générées sur le téléphone et la clé privée ne quitte jamais l'appareil. Découvrez le terminal SSH pour votre téléphone, téléchargez termi1 pour iPhone ou consultez le centre d'assistance technique.

Questions fréquentes

Où placer NOPASSWD dans une règle sudoers ?

NOPASSWD se place dans une règle sudoers juste avant la commande, après les deux-points : deploy ALL=(root) NOPASSWD: /usr/bin/systemctl reload nginx. L'étiquette s'applique aussi aux commandes suivantes de la même ligne, donc limitez cette ligne à la seule commande que vous voulez autoriser sans mot de passe.

Pourquoi mon fichier dans /etc/sudoers.d ne fonctionne-t-il pas ?

Un fichier dans /etc/sudoers.d échoue généralement pour l'une de trois raisons : son nom contient un point ou se termine par ~, une règle ultérieure exige un mot de passe et l'annule, ou le chemin de la commande ne correspond pas exactement. Vérifiez avec sudo visudo -c et sudo -l lancé par cet utilisateur.

Que se passe-t-il si j'enregistre sudoers avec une erreur de syntaxe ?

Enregistrer sudoers avec une erreur de syntaxe peut rendre sudo inutilisable pour tous les utilisateurs. visudo l'empêche, car il vérifie la syntaxe avant d'enregistrer et signale l'erreur. Si vous modifiez le fichier avec un autre éditeur et le cassez, il vous faudra un shell root déjà ouvert ou la console de récupération.

Est-il sûr de donner NOPASSWD à mon propre script ?

Donner NOPASSWD à votre script n'est sûr que s'il appartient à root et qu'aucun autre utilisateur ne peut le modifier. Si l'utilisateur titulaire de la permission sudo peut éditer le script, il peut y ajouter n'importe quelle commande et l'exécuter en root sans mot de passe. Utilisez toujours des chemins absolus et des arguments fixes.