Problème avec sudo

Support Debian
#1

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

#2

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/.

#3

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
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

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.

#4

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

#5

J’ai bien mis cette ligne dans le fichier sudoers, mais toujours le même problème

#6

Dans mon cas, installation tout à fait standard, le fichier par défaut est sous /etc
Bon courage

#7

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 :

getent password debian

groups debian
#8

Alors,

Le sudoers est le fichier standard comme le répertoire /etc/sudoers.d aussi puisque nouvelle installation:
sudoers

#
# 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

# 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:

 getent password debian
Unknown database: password
Try `getent --help' or `getent --usage' for more information.

Donc j’ai fait:

getent passwd debian
debian:x:1000:1000:Debian:/home/debian:/bin/bash

et

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

#9

Jamais eu d’utilisateur debian avec installation par cd
Par contre dans ton cas on voit qu’il est créé par cloud-init
Kesako ?

#10

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.

1 J'aime
#11

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 …

#12

Non, c’est la configuration par défaut de sshd.

PermitRootLogin probibit-password
#13

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

#14

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).

#15

OVH, sur serveur kimsufi

#16

C’est donc que tu as choisi « Debian IAAS » comme template d’installation au lieu d’une debian standard.

#17

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

#18

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.

#19

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) 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

#20

debianIAAS

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.