Je viens de tomber là-dessus aussi.

Ma situation est que je suis en train de configurer un système distant qui fonctionnera sans tête. J'ai activé le chiffrement complet du disque (sinon un attaquant avec un accès physique peut faire ce qu'il veut) Je veux une authentification avec seulement une clé publique (je vais désactiver le mot de passe de sorte que le schéma "avoir quelque chose, savoir quelque chose" soit une paire de clés protégée par mot de passe -- l'authentification root est bien sûr entièrement désactivée)

L'installeur d'Ubuntu demande un utilisateur admin non root qui est ajouté au groupe sudo. J'avais ensuite ajouté manuellement mon utilisateur au fichier sudoers en utilisant sudo visudo :

mon_nom_utilisateur ALL=(ALL:ALL) NOPASSWD:ALL

REMARQUE si vous utilisez NOPASSWD sur votre ordinateur portable, vous devez toujours verrouiller votre ordinateur en vous éloignant sinon un attaquant occasionnel peut compromettre beaucoup de choses pendant que vous vous levez pour mettre de la crème dans votre café

Je devais toujours m'authentifier avec un mot de passe.

La réponse d'enzotib est la clé de ce qui se passe. Le groupe sudo apparaît dans sudoers après l'entrée pour mon nom d'utilisateur.

Au lieu de déplacer mon entrée en dessous de la ligne sudo, j'ai simplement supprimé la ligne que j'avais ajoutée précédemment et ensuite ajouté NOPASSWD à l'entrée pour %sudo

Cela semble fonctionner. À nouveau, n'utilisez NOPASSWD que si vous en avez vraiment besoin (Dans mon cas, c'était exactement ce dont j'avais besoin, pour la plupart des utilisateurs, exiger un mot de passe pour les activités sudo est préférable)

AVERTISSEMENT supplémentaire : Modifiez toujours sudoers avec visudo. (sudo visudo) De plus, avoir une autre fenêtre ouverte basculée vers l'utilisateur root vous permet de récupérer toutes les erreurs que vous pourriez commettre en modifiant le fichier sudoers.

Idéalement, si vous personnalisez les commandes pouvant être exécutées via sudo, vous devriez apporter ces modifications dans un fichier séparé sous /etc/sudoers.d/ au lieu de modifier directement le fichier sudoers. Vous devriez également toujours utiliser visudo pour éditer le(s) fichier(s).

Exemple : sudo visudo -f /etc/sudoers.d/slowcpu

Insérez votre ligne accordant l'autorisation : gatoatigrado ALL=NOPASSWD: /bin/set-slow-cpufreq

Ensuite, enregistrez et quittez, et visudo vous avertira en cas d'erreurs de syntaxe.

Vous pouvez exécuter sudo -l pour voir les autorisations qui ont été accordées à votre utilisateur, si des commandes spécifiques à l'utilisateur NOPASSWD apparaissent AVANT toute commande %groupyouarein ALL=(ALL) ALL dans la sortie, vous devrez entrer votre mot de passe.

Si vous vous retrouvez à créer beaucoup de ces fichiers sudoers.d, vous voudrez peut-être les nommer par utilisateur pour les visualiser plus facilement. Gardez à l'esprit que l'ordre des NOMS DE FICHIERS et des RÈGLES à l'intérieur du fichier est très important, le DERNIER chargé l'emporte, qu'il soit PLUS ou MOINS permissif que les entrées précédentes.

Vous pouvez contrôler l'ordre des noms de fichiers en utilisant un préfixe de 00-99 ou aa/bb/cc, mais gardez également à l'esprit que si vous avez DES fichiers sans préfixe numérique, ils se chargeront après les fichiers numérotés, remplaçant les paramètres. Cela est dû au fait que, en fonction de vos paramètres linguistiques, le "tri lexical" utilisé par l'interpréteur classe d'abord les nombres puis peut entrelacer les majuscules et les minuscules lors du tri dans l'ordre "croissant".

Essayez d'exécuter printf '%s\n' {{0..99},{A-Z},{a-z}} | sort et printf '%s\n' {{0..99},{A-Z},{a-z}} | LANG=C sort pour voir si votre langue actuelle imprime AaBbCc etc. ou ABC, puis abc pour déterminer quel préfixe de "dernière" lettre serait le meilleur à utiliser.

En plus de la réponse de @enzotib (ajoutez la ligne à la fin de /etc/sudoers), assurez-vous également de regarder /etc/sudoers.d. Après une installation de Debian Buster, j'avais ce fichier

$ sudo cat /etc/sudoers.d/10-installer
%sudo ALL=(ALL) ALL

qui a écrasé ma règle à la fin du fichier sudoers. Curieusement, j'avais aussi la ligne

# Autoriser les membres du groupe sudo à exécuter n'importe quelle commande
%sudo   ALL=(ALL:ALL) ALL

dans /etc/sudoers. Par conséquent, je suppose que /etc/sudoers.d/10-installer est un artefact de l'installation. Je l'ai supprimé et maintenant ça fonctionne.

Sur le système distant, supprimez le cryptage, mais laissez tout être la propriété d'un utilisateur root comme dans le groupe des "Administrateurs" - qui n'est pas 0 !
Vous pouvez modifier #sudo -g Administrators pour ceux qui ont besoin d'un accès complet - pas dans le fichier sudo, mais dans le profil .login. Tout script standard peut maintenant avoir accès au système distant en tant que "root" et vous pouvez protéger les fichiers qui doivent l'être.
Un autre groupe pratique est "Sandbox" avec un répertoire d'accueil dans le cache du navigateur et peut lire ceci librement et rien d'autre. Utilisez une majuscule en première lettre.