# Problème avec sudo **URL:** \ **Category:** Support Debian\ **Created:** [Juillet 7, 2020, 7:51 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476 "2020-07-07T19:51:33Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Sfullak](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/cdc98d/32.png) [@Sfullak](https://www.debian-fr.org/u/Sfullak)\ **Post date:** [Juillet 7, 2020, 7:51 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/1 "2020-07-07T19:51:33Z")
Bonjour, J’ai un soucis avec sudo sur mon serveur dedié ( 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1+deb10u1 (2020-0 4-27) x86\_64) qui est à jour: J’ai retiré l’utilisateur _debian_ du groupe sudo (et de tous les autres groupes dont il faisait partie, sauf _debian_), et pourtant, en me loguant avec (via ssh) puis en tapant `sudo -s` j’arrive à me loguer en root. Cet utilisateur _debian_ est-il spécial dans debian (ce que je ne pense pas) ou il y a autre chose à faire pour qu’il ne puisse plus se loguer en root avec la commande sudo ? PS: J’ai aussi remarqué que sudo ne demandait pas le mot de passe utilisateur (sauf lor de sa première utilisation par un nouvel utilisateur: c’est la mon problème ? Denis ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juillet 8, 2020, 8:09 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/2 "2020-07-08T08:09:44Z")
L’appartenance au groupe sudo n’est pas le seul moyen d’attribuer des privilèges aux utilisateurs. Il y a aussi le fichier /etc/sudoers et les fichiers contenus dans /etc/sudoers.d/. ---
**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\ **Post date:** [Juillet 8, 2020, 8:50 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/3 "2020-07-08T08:50:37Z")
sudo autorise l’action d’un utilisateur pendant 15 mn, ça peut se modifier Voir [https://manpages.debian.org/buster/sudo-ldap/sudoers.5.en.html](https://manpages.debian.org/buster/sudo-ldap/sudoers.5.en.html) `sudoers` uses per-user time stamp files for credential caching. Once a user has been authenticated, a record is written containing the user ID that was used to authenticate, the terminal session ID, the start time of the session leader (or parent process) and a time stamp (using a monotonic clock if one is available). The user may then use `sudo` without a password for a short period of time ( `15` minutes unless overridden by the _timestamp\_timeout_ option). By default, `sudoers` uses a separate record for each terminal, which means that a user’s login sessions are authenticated separately. The _timestamp\_type_ option can be used to select the type of time stamp record `sudoers` will use. [https://debian-facile.org/doc:systeme:sudo](https://debian-facile.org/doc:systeme:sudo) Droits d’exécution à une seule commande Sous la ligne : Defaults env\_reset Ajoutez : Defaults timestamp\_timeout=0 En mettant le timeout à 0, les droits root ne seront plus utilisables dès que vous aurez validé l’exécution de votre commande. ---
**Author:** ![Sfullak](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/cdc98d/32.png) [@Sfullak](https://www.debian-fr.org/u/Sfullak)\ **Post date:** [Juillet 8, 2020, 10:41 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/4 "2020-07-08T10:41:16Z")
Merci pour vos réponses, mais: J’avais bien vérifié /etc/sudoers ainsi que le répertoire /etc/sudoers.d/ : ras « sudo autorise l’action d’un utilisateur pendant 15 mn » : dans mon cas, nouveaau test ce midi (donc plus de 12h): toujours possible sans demande de mot de passe… J’ai recherché le fichier sudo.conf sur mon serveur: introuvable: j’ai donc fait: apt purge sudo suivi de apt install sudo et ce fichier sudo.conf est toujours introuvable =\> normal, il n’existe pas. Et l’utilisateur debian a toujours accès à root avec sudo -s ---
**Author:** ![Sfullak](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/cdc98d/32.png) [@Sfullak](https://www.debian-fr.org/u/Sfullak)\ **Post date:** [Juillet 8, 2020, 10:57 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/5 "2020-07-08T10:57:09Z")
> [@grandtoubab](#): > > Defaults timestamp\_timeout=0 J’ai bien mis cette ligne dans le fichier sudoers, mais toujours le même problème ---
**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\ **Post date:** [Juillet 8, 2020, 11:39 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/6 "2020-07-08T11:39:32Z")
Dans mon cas, installation tout à fait standard, le fichier par défaut est sous /etc Bon courage ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juillet 8, 2020, 3:25 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/7 "2020-07-08T15:25:19Z")
Plutôt que nous dire « ras « il aurait été plus utile de nous donner le contenu des fichiers en question : /etc/sudoers et ceux sous /etc/sudoers.d Le retour de ces commandes pourrait aussi aider : ```nohighlight getent password debian ``` ```nohighlight groups debian ``` ---
**Author:** ![Sfullak](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/cdc98d/32.png) [@Sfullak](https://www.debian-fr.org/u/Sfullak)\ **Post date:** [Juillet 8, 2020, 3:55 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/8 "2020-07-08T15:55:32Z")
Alors, Le sudoers est le fichier standard comme le répertoire /etc/sudoers.d aussi puisque nouvelle installation: sudoers ```nohighlight # # This file MUST be edited with the 'visudo' command as root. # # Please consider adding local content in /etc/sudoers.d/ instead of # directly modifying this file. # # See the man page for details on how to write a sudoers file. # Defaults env_reset Defaults timestamp_timeout=0 Defaults mail_badpass Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" # Host alias specification # User alias specification # Cmnd alias specification # User privilege specification root ALL=(ALL:ALL) ALL # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL # See sudoers(5) for more information on "#include" directives: #includedir /etc/sudoers.d ``` Et etc/sudoers.d contient les fichiers 90-cloud-init-users debian-cloud-init README et le fichier 90-cloud-init-users contient ```nohighlight # Created by cloud-init v. 18.3 on Tue, 11 Feb 2020 10:00:53 +0000 # User rules for debian debian ALL=(ALL) NOPASSWD:ALL # User rules for debian debian ALL=(ALL) NOPASSWD:ALL ``` Et idem dans le fichier debian-cloud-init Pour les deux commandes: ```nohighlight getent password debian Unknown database: password Try `getent --help' or `getent --usage' for more information. ``` Donc j’ai fait: ```nohighlight getent passwd debian debian:x:1000:1000:Debian:/home/debian:/bin/bash ``` et ```nohighlight groups debian debian : debian ``` J’ai donc supprimé donc les deux fichiers contenus dans /etc/sudoers.d/, installé par le package sudo de debian, car c’est la que mon utilisateur debian existe. Mais si je suis dans ce cas, je ne dois pas être le seul, qu’un package donne des droits de superutilisateur à un utilisateur autre que root par défaut, sans l’annoncer, je trouve çà moyen/bof Enfin, merci, problème résolu ---
**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\ **Post date:** [Juillet 8, 2020, 6:49 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/9 "2020-07-08T18:49:11Z")
Jamais eu d’utilisateur debian avec installation par cd Par contre dans ton cas on voit qu’il est créé par cloud-init Kesako ? ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juillet 8, 2020, 6:51 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/10 "2020-07-08T18:51:13Z")
> [@Sfullak](#): > > J’avais bien vérifié /etc/sudoers ainsi que le répertoire /etc/sudoers.d/ : ras C’est donc bien dans sudoers que l’utilisateur _debian_ était autorisé à lancer toute commande sans mot de passe. Mais bon « ras »… Ces configurations ne sont pas arrivées là par hasard mais bien parce que tu as installé puis (mal) configuré cloud-init. ---
**Author:** ![Sfullak](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/cdc98d/32.png) [@Sfullak](https://www.debian-fr.org/u/Sfullak)\ **Post date:** [Juillet 8, 2020, 10:23 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/11 "2020-07-08T22:23:01Z")
Oui, pour le ras, je me suis trompé, j’avais bien vu les fichiers et les avait consulté, mais cela ne m’avait pas sauté aux yeux. Mais ces deux fichiers, ce n’est pas moi qui les ai mis: comme indiqué, je suis sur un serveur dédié (donc pas du cloud). L’installation est faites depuis l’interface web de mon hébergeur qui installe un linux normalement « propre », c’est donc lui qui doit créer cette configuration pendant l’installation de la machine. (c’est lui d’ailleurs qui donne comme accès à la machine l’utilisateur « debian » et son mdp … Merci à vous deux, je sais maintenant que c’est mon hébergeur du dédié qui est la cause de ce soucis, en interdisant par défaut le login de root via SSH, mais en créant un utilisateur qui a les mêmes pouvoirs, sans avoir besoin de mdp … ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juillet 9, 2020, 5:44 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/12 "2020-07-09T05:44:25Z")
> [@Sfullak](#): > > c’est mon hébergeur du dédié qui est la cause de ce soucis, en interdisant par défaut le login de root via SSH Non, c’est la configuration par défaut de sshd. ``` PermitRootLogin probibit-password ``` ---
**Author:** ![Sfullak](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/cdc98d/32.png) [@Sfullak](https://www.debian-fr.org/u/Sfullak)\ **Post date:** [Juillet 9, 2020, 6:11 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/13 "2020-07-09T06:11:42Z")
Si la valeur par defaut est comme tu le dis, `PermitRootLogin probibit-password` alors c’est bien mon hébergeur qui a mis , comme je le disais, `PermitRootLogin no` ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juillet 9, 2020, 7:14 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/14 "2020-07-09T07:14:02Z")
Par curiosité quel hébergeur et quel type de serveur ? J’ai du mal à croire qu’un hébergeur ait un modèle d’installation avec cloud-init installé et configuré ainsi (avec des doublons) et le sshd\_config interdisant une connexion directe en root (_PermitRootLogin no_). ---
**Author:** ![Sfullak](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/cdc98d/32.png) [@Sfullak](https://www.debian-fr.org/u/Sfullak)\ **Post date:** [Juillet 9, 2020, 10:09 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/15 "2020-07-09T10:09:09Z")
OVH, sur serveur kimsufi ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juillet 9, 2020, 10:31 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/16 "2020-07-09T10:31:53Z")
C’est donc que tu as choisi « Debian IAAS » comme template d’installation au lieu d’une debian standard. ---
**Author:** ![Sfullak](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/cdc98d/32.png) [@Sfullak](https://www.debian-fr.org/u/Sfullak)\ **Post date:** [Juillet 9, 2020, 11:06 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/17 "2020-07-09T11:06:04Z")
Je ne pense pas, ne sachant même pas ce que signifie IAAS, et ce template ne m’ai pas proposé (je viens de vérifier) mais en debian, seulement le template > Debian 10 (Buster) - debian10 64 bits ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juillet 9, 2020, 11:50 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/18 "2020-07-09T11:50:04Z")
Je peux t’assurer que ce template est proposé par OVH/Kimsufi sauf sur les serveurs très bas de gamme à base à processeurs Atom. IAAS = Infrastructure As A Service. Les autres templates debian fournissent une distribution standard (à quelques configurations près), n’installent pas cloud-init et ne créent pas d’utilisateur _debian_. De mémoire, même sudo n’est pas installé par défaut. Ce que tu constates sur ton serveur est donc du à des installation et configuration réalisés a posteriori par l’administrateur système. ---
**Author:** ![Sfullak](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/cdc98d/32.png) [@Sfullak](https://www.debian-fr.org/u/Sfullak)\ **Post date:** [Juillet 9, 2020, 3:42 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/19 "2020-07-09T15:42:47Z")
Il n’y a que moi qui administre le système et je te reconfirmes que je n’ai pas ce template IAAS de disponible pour ce serveur (voir screen [https://www.casimages.com/i/2007090554403298.jpg.html](https://www.casimages.com/i/2007090554403298.jpg.html)) qui est un Kimsufi 16G avec processeur Intel® Xeon® CPU E3-1225 V2 @ 3.20GHz, et que je n’ai pas configuré à posteriori le packet sudo. Denis ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juillet 9, 2020, 4:49 UTC](https://www.debian-fr.org/t/probleme-avec-sudo/82476/20 "2020-07-09T16:49:41Z")
![debianIAAS](https://www.debian-fr.org/uploads/default/original/2X/3/3e9ed3f41d3c440871d61bfe83440463c410eb32.png) Mais ton Kimsufi 16G est une ancienne offre qui a disparu depuis plusieurs années, c’est donc possible que tu n’ai pas accès aux mêmes options d’installation. [Page suivante](https://www.debian-fr.org/t/probleme-avec-sudo/82476.md?page=2)