en utilisant la commande SUDO le systéme me renvoie le message suivant: « ac3845 » (qui doit être le login que j’ai rentré dans le système lors de l’installation de Debian 10 ) il n’apparaît pas dans le fichier « SUDOERS »
avez-vous une réponse S V P avec une solution merci d’avance
bonsoir,
dans le fichier sudoers doit être défini un groupe. Et si tu regarde les membres du groupe, le user ac3845 doit en faire partie.
Bonjour baboun38
Si, au moment de l’installation de ton système debian,
tu as donné un mot de passe au compte root
la commande sudo ne sera pas installée automatiquement
et les comptes utilisateur non privilégiées qui seront créés
ne seront pas dans le groupe des sudoers
Dans ce cas là, pour accéder aux privilèges du compte root
il suffit simplement de se connecter au compte root
en utilisant la ligne de commande suivante :
su -
et d’entrer ensuite le mot de passe du compte root que tu lui avais donné au cours de l’installation de ton système debian.
Si au moment de l’installation de ton système debian,
tu n’as PAS donné de mot de passe au compte root
la commande sudo sera automatiquement installée
et le premier compte utilisateur non privilégié
sera automatiquement ajouté dans la liste des sudoers
Dans ce cas là, pour accéder aux privilèges du compte root pour lancer une commande
il suffit de la faire précéder par la commande sudo
Et si l’on veut se connecter sous le compte root
il suffit d’entrer la ligne de commande suivante :
sudo -i
Au cours de l’installation de ton système debian,
as-tu donné un mot de passe au compte root ?
en fait tu met un mot de passe à root, ensuite tu te connecte en root sur la console ou en utilisant su -, tu installes sudo via apt install sudo et tu ajoute ton user au groupe sudo (il me semble que le fichier /etc/sudoers est configuré par defaut pour donner l’accès root au groupe sudo).
Car il n’est pas souhaitable en terme de sécurité de laisser le compte root sans mot de passe.
Pourquoi « en terme de sécurité » ? Sans mot de passe != mot de passe vide.
Si je ne m’abuse ce n’est jamais le cas
Il suffit d’aller ds /etc/shadow pour vérifier
Il me semble que si tu installes linux sans mdp root il y en a qd meme un mais désactivé => ("!")
Bonjour merci de vos retours
Le super utilisateur a déjà un mot de passe Il me semble que le superutilisateur est égal a root
Qu’est-ce qui n’est jamais le cas ?
Non, il n’y en a pas. Mot de passe désactivé ou absent, techniquement ça revient au même.
1 J'aime
En effet je viens de revérifier, mea culpa
Un des cas est tout simplement d’avoir le sudo cassé 
Sinon pour préciser, désactiver complètement root est une chose, mais ne pas avoir de mot de passe pour root en est une autre, mauvaise de surcroit.
Un root sans mot de passe peut être attaqué en brute force par exemple.
Peux-tu préciser ce que tu entends pas « cassé », et en quoi sudo cassé et pas de mot de passe root impacte la sécurité ?
Comment ? Aucun mot de passe ne marchera.
Pas avec un mot de passe vide. Oui avec un compte désactivé.
Comment un mot de passe pourrait-il marcher avec un compte désactivé ?
Je parle de compte sans mot de passe, pas de mot de passe vide.
Si tu parles dans /etc/shadow d’avoir root:*:… ou root:!.. le compte est désactivé pour l’authentification (j’aurais du préciser un peu plus semble-t-il), si tu as root::… tu as le compte avec un mot de passe vide.
Ceci dit si le mot de passe root est desactivé, en cas de disaster recovery, pas moyen de démarrer en single-user mode en ayant accès à la machine.
S’il y a des problèmes du genre kernel/initramfs, /etc/fstab mount, avec un disque plus ou moins corrompu. Sans mot de passe root, pas moyen d’agir.
J’utilise toujours un mot de passe root. Il est complètement aléatoire, d’un nombre de caractère supérieur à 15. Dans certains cas je ne le connais même pas. En cas de gros soucis, je peux toujours faire un single-mode user, ou un rescue media, sinon c’est mort.
Pour ce qui est d’un sudo « cassé » il suffit d’une mauvaise manip de configuration pour que celui-ci ne marche pas.
Oui, je parle de ça, et non, le compte n’est pas désactivé, c’est seulement le mot de passe qui est désactivé. On peut s’authentifier par d’autres moyens, comme une clé SSH. Mais évidemment ça bloque tout accès qui ne supporte que l’authentification par mot de passe.
J’ai cru comprendre qu’Ubuntu permet d’utiliser le mode recovery sans mot de passe root, mais j’ignore s’il faut fournir le mot de passe d’un sudoer ou pas.
C’est bien le problème de l’installation sans mot de passe root. Ou plutôt un des problèmes, car il y en a d’autres, comme en cas d’impossibilité d’ouvrir une session normale pour pouvoir utiliser sudo.
Si, il reste des moyens d’agir : ajouter le paramètre du noyau « break » pour arrêter le démarrage sur le shell de l’initramfs, ou « init=/bin/bash » pour démarrer directement avec un shell root. Sans parler de démarrer avec un autre système.
je prends note pour celui là, je pensais que justement ce serait bloqué.
je ne savais pas pour le break.
Pour le redémarrage avec un autre système, sur le cas de mon serveur tu ne peux pas, les médias externe sont désactivés.
Bon après tu peux toujours démonter la machine et mettre un disque de plus dedans pour démarrer dessus, mais là, c’est déjà plus lourd.
Lorsque le démarrage utilise un initramfs, certains paramètres comme bien sûr root= mais aussi init= ne sont plus interprétés par le noyau mais laissés à la libre interprétation de l’initramfs. Donc pas besoin de le bloquer, il suffit de ne pas le prendre en compte dans l’initramfs. Ceci dit on peut encore utiliser le paramètre rdinit= pour spécifier le programme à exécuter dans l’initramfs au lieu du programme par défaut (mais on risque de se retrouver sans clavier si connecté en USB). L’initramfs de Debian constuit par initramfs-tools prend en compte le paramètre init (comme root=, ro, rw…), mais ce n’est pas forcément le cas de tous.
Pour empêcher le premier venu d’abuser de ces fonctionnalités, l’usage est de protéger le menu de GRUB par un mot de passe.
Et il n’y a pas moyen de les réactiver dans les cas d’urgence ?
Ou plus simplement prévoir un système minimal de secours installé sur un bout de disque interne. Ça ne couvre pas tous les cas mais au moins tous ceux où le chargeur d’amorçage et le système de secours sont intacts.
Oui j’utilise aussi avec une génération automatique du MDP a récupérer à la première connexion sur le système.
l’USB éventuellement. Mais l’accès au disque qui est crypté ne sert à rien si on ne peut pas faire un rescue.
sauf qu’on se retrouve avec le même problème avec le système minimal 
Pourquoi ?
Pas si le problème n’affecte que le système principal.
Certes, donc autant prévoir sur un disque séparé.
mal formulé. Comme le système est sur un disque chiffré, un autre disque de rescue ne pourra pas le déchiffrer . La clé de chiffrement n’est pas un mot de passe mais un certificat obtenu par une clef de sécurité non accessible (m’enfin tu peux casser le truc mais c’est moins fun ).
si j’ai bien compris le certificat est lié au disque. Donc Si tu essaye de l’utiliser avec un autre disque ça ne marche pas. Je ne maitrise pas cette partie.