Est-il ok de configurer un `sudo` sans mot de passe sur un serveur cloud ?

Dans certains cas, il est nécessaire de le faire. par exemple certains API hyperviseurs nécessitent une connexion sans mot de passe et sans sudo. Mais vous pouvez toujours restreindre cela sans casser.

Pour ce que vous essayez d'accomplir. Je dirais, habituez-vous à taper un mot de passe. La sécurité est plus pratique que la commodité ici. D'ailleurs, si vous avez vraiment besoin d'un accès root, vous pouvez utiliser sudo et il mettra en cache les informations d'identification pendant un certain temps afin que si vous exécutez plusieurs commandes sudo à la suite, il ne demandera que le mot de passe la première fois. Donc ce n'est pas une si grande gêne que vous le supposez.

Aussi, si vous tapez un grand nombre de commandes avec des privilèges root et que vous ne voulez pas mettre sudo au début à chaque fois, vous pouvez soit utiliser su ou sudo -s pour obtenir un shell root. Vous saisirez votre mot de passe une fois et c'est tout.

Une fois, j'ai été piégé par le sudo sans mot de passe. C'était un script shell, un installateur quelconque qui appelait sudo en mon nom au lieu de simplement exiger sudo ou afficher une erreur.

Imaginez taper 'make' et le script faisant la partie 'sudo make install' pour vous, sans configurer ou afficher le chemin de base, et le script étant si stupide au départ que vous n'êtes pas sûr qu'ils connaissent /usr/local et donc vous commencez à vérifier /usr pour des modifications...

J'ai promis de ne plus jamais utiliser NOPASSWD et j'ai aussi changé ce paramètre de délai à 0.

Les autres réponses ici sont excellentes et abordent la plupart des points importants. Une chose que je n'ai pas vue mentionnée est le fait que tout type d'authentification que vous effectuez lorsque vous êtes connecté peut être capturé par un attaquant distant qui a déjà établi une position dans votre compte. Ils peuvent modifier vos fichiers de connexion shell ou PATH pour installer un enregistreur de frappe de sorte que tout ce que vous tapez, y compris votre mot de passe sudo, leur soit envoyé. Ils pourraient ajouter un binaire sudo piraté à votre PATH pour collecter votre mot de passe. Ils peuvent détourner la connexion ssh de l'agent vers votre machine connectée pour contourner pam_ssh_agent_auth et devenir root dès que vous vous connectez. Donc, en termes de sécurité absolue, je ne vois pas de différence entre l'utilisation d'un mot de passe pour sudo et pas du tout. Bien sûr, cela rend l'attaque plus compliquée, et ils obtiennent les droits root une fois que vous avez utilisé sudo une fois, plutôt que immédiatement.

En résumé, je crois que la seule façon d'empêcher absolument qu'un compte utilisateur compromis devienne root si vous avez accès sudo est de supprimer l'accès sudo de vous-même, ou de ne jamais l'utiliser. Si vous n'êtes pas d'accord, faites-le moi savoir, car j'adorerais avoir tort !

Alors que cela ne répond pas strictement à votre question, une autre option pourrait être de définir un timestamp_timeout plus long pour ne pas avoir à taper votre mot de passe aussi souvent. Cela empêchera n'importe qui d'obtenir des privilèges d'administrateur, tout en réduisant vos désagréments.

De la page man des sudoers:

timestamp_timeout

Nombre de minutes pouvant s'écouler avant que sudo ne demande à nouveau un mot de passe. Le délai peut inclure un composant fractionnaire si la granularité de la minute est insuffisante, par exemple 2,5. La valeur par défaut est 5. Définissez-la sur 0 pour toujours demander un mot de passe. Si elle est définie sur une valeur inférieure à 0, le jeton temporel de l'utilisateur n'expirera jamais. Ceci peut être utilisé pour permettre aux utilisateurs de créer ou de supprimer leurs propres jetons temporels via "sudo -v" et "sudo -k" respectivement.

Ce billet de blog montre quelques exemples utilisant visudo pour définir le délai en minutes, par exemple:

Defaults timestamp_timeout=60

Peut-être que c'est un compromis intéressant entre sécurité et facilité d'utilisation?