# Commande sudo

**URL:** <https://www.debian-fr.org/t/commande-sudo/84037>\
**Category:** Support Debian\
**Created:** [Février 18, 2021, 9:17 UTC](https://www.debian-fr.org/t/commande-sudo/84037 "2021-02-18T21:17:49Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![baboun38](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/dc4da7/32.png) [@baboun38](https://www.debian-fr.org/u/baboun38)\
**Post date:** [Février 18, 2021, 9:17 UTC](https://www.debian-fr.org/t/commande-sudo/84037/1 "2021-02-18T21:17:49Z")

</div>

en utilisant la commande SUDO le systéme me renvoie le message suivant: «&nbsp;ac3845&nbsp;» (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 «&nbsp;SUDOERS&nbsp;»  
avez-vous une réponse S V P avec une solution merci d’avance

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Février 18, 2021, 9:22 UTC](https://www.debian-fr.org/t/commande-sudo/84037/2 "2021-02-18T21:22:30Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Février 18, 2021, 10:31 UTC](https://www.debian-fr.org/t/commande-sudo/84037/3 "2021-02-18T22:31:14Z")

</div>

Bonjour [**baboun38**](https://www.debian-fr.org/u/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 :

```auto
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 :

```auto
sudo -i

```

* * *

Au cours de l’installation de ton système debian,  
as-tu donné un mot de passe au compte **`root`**?

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Février 18, 2021, 11:12 UTC](https://www.debian-fr.org/t/commande-sudo/84037/4 "2021-02-18T23:12:38Z")

</div>

> [@anon29980398](#):
>
> 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

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.

---

<div class="post-metadata">

**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:** [Février 19, 2021, 6:04 UTC](https://www.debian-fr.org/t/commande-sudo/84037/5 "2021-02-19T06:04:42Z")

</div>

> [@Zargos](#):
>
> il n’est pas souhaitable en terme de sécurité de laisser le compte root sans mot de passe

Pourquoi «&nbsp;en terme de sécurité&nbsp;» ? Sans mot de passe != mot de passe vide.

---

<div class="post-metadata">

**Author:** ![anon90668717](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/3e96dc/32.png) [@anon90668717](https://www.debian-fr.org/u/anon90668717)\
**Post date:** [Février 19, 2021, 6:41 UTC](https://www.debian-fr.org/t/commande-sudo/84037/6 "2021-02-19T06:41:20Z")

</div>

> [@PascalHambourg](#):
>
> 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é =\> («&nbsp;!&nbsp;»)

---

<div class="post-metadata">

**Author:** ![baboun38](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/dc4da7/32.png) [@baboun38](https://www.debian-fr.org/u/baboun38)\
**Post date:** [Février 19, 2021, 8:30 UTC](https://www.debian-fr.org/t/commande-sudo/84037/7 "2021-02-19T08:30:11Z")

</div>

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

---

<div class="post-metadata">

**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:** [Février 21, 2021, 10:30 UTC](https://www.debian-fr.org/t/commande-sudo/84037/8 "2021-02-21T10:30:03Z")

</div>

> [@anon90668717](#):
>
> > [@PascalHambourg](#):
> >
> > Sans mot de passe != mot de passe vide
> 
> Si je ne m’abuse ce n’est jamais le cas

Qu’est-ce qui n’est jamais le cas ?

> [@anon90668717](#):
>
> si tu installes linux sans mdp root il y en a qd meme un mais désactivé =\> («&nbsp;!&nbsp;»)

Non, il n’y en a pas. Mot de passe désactivé ou absent, techniquement ça revient au même.

---

<div class="post-metadata">

**Author:** ![anon90668717](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/3e96dc/32.png) [@anon90668717](https://www.debian-fr.org/u/anon90668717)\
**Post date:** [Février 21, 2021, 2:59 UTC](https://www.debian-fr.org/t/commande-sudo/84037/9 "2021-02-21T14:59:11Z")

</div>

> [@PascalHambourg](#):
>
> Non, il n’y en a pas.

En effet je viens de revérifier, mea culpa

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Février 25, 2021, 12:48 UTC](https://www.debian-fr.org/t/commande-sudo/84037/10 "2021-02-25T12:48:08Z")

</div>

> [@PascalHambourg](#):
>
> Pourquoi « en terme de sécurité » ? Sans mot de passe != mot de passe vide.

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.

---

<div class="post-metadata">

**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:** [Février 27, 2021, 8:18 UTC](https://www.debian-fr.org/t/commande-sudo/84037/11 "2021-02-27T08:18:51Z")

</div>

> [@Zargos](#):
>
> Un des cas est tout simplement d’avoir le sudo cassé

Peux-tu préciser ce que tu entends pas «&nbsp;cassé&nbsp;», et en quoi sudo cassé et pas de mot de passe root impacte la sécurité ?

> [@Zargos](#):
>
> Un root sans mot de passe peut être attaqué en brute force par exemple.

Comment ? Aucun mot de passe ne marchera.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Mars 1, 2021, 1:32 UTC](https://www.debian-fr.org/t/commande-sudo/84037/12 "2021-03-01T13:32:25Z")

</div>

> [@PascalHambourg](#):
>
> Comment ? Aucun mot de passe ne marchera.

Pas avec un mot de passe vide. Oui avec un compte désactivé.

---

<div class="post-metadata">

**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:** [Mars 1, 2021, 2:01 UTC](https://www.debian-fr.org/t/commande-sudo/84037/13 "2021-03-01T14:01:07Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Mars 1, 2021, 2:31 UTC](https://www.debian-fr.org/t/commande-sudo/84037/14 "2021-03-01T14:31:37Z")

</div>

> [@PascalHambourg](#):
>
> 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 «&nbsp;cassé&nbsp;» il suffit d’une mauvaise manip de configuration pour que celui-ci ne marche pas.

---

<div class="post-metadata">

**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:** [Mars 1, 2021, 2:49 UTC](https://www.debian-fr.org/t/commande-sudo/84037/15 "2021-03-01T14:49:13Z")

</div>

> [@Zargos](#):
>
> Si tu parles dans /etc/shadow d’avoir root:\*:… ou root:!.. le compte est désactivé pour l’authentification

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.

> [@Zargos](#):
>
> 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.

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.

> [@Zargos](#):
>
> 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.

Si, il reste des moyens d’agir : ajouter le paramètre du noyau «&nbsp;break&nbsp;» pour arrêter le démarrage sur le shell de l’initramfs, ou «&nbsp;init=/bin/bash&nbsp;» pour démarrer directement avec un shell root. Sans parler de démarrer avec un autre système.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Mars 1, 2021, 2:54 UTC](https://www.debian-fr.org/t/commande-sudo/84037/16 "2021-03-01T14:54:43Z")

</div>

> [@PascalHambourg](#):
>
> « init=/bin/bash » pour démarrer directement avec un shell root

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.

---

<div class="post-metadata">

**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:** [Mars 1, 2021, 3:19 UTC](https://www.debian-fr.org/t/commande-sudo/84037/17 "2021-03-01T15:19:26Z")

</div>

> [@Zargos](#):
>
> je pensais que justement ce serait bloqué.

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.

> [@Zargos](#):
>
> 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.

Et il n’y a pas moyen de les réactiver dans les cas d’urgence ?

> [@Zargos](#):
>
> tu peux toujours démonter la machine et mettre un disque de plus dedans pour démarrer dessus

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.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Mars 1, 2021, 3:23 UTC](https://www.debian-fr.org/t/commande-sudo/84037/18 "2021-03-01T15:23:58Z")

</div>

> [@PascalHambourg](#):
>
> 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.

Oui j’utilise aussi avec une génération automatique du MDP a récupérer à la première connexion sur le système.

> [@PascalHambourg](#):
>
> Et il n’y a pas moyen de les réactiver dans les cas d’urgence ?

l’USB éventuellement. Mais l’accès au disque qui est crypté ne sert à rien si on ne peut pas faire un rescue.

> [@PascalHambourg](#):
>
> 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.

sauf qu’on se retrouve avec le même problème avec le système minimal 😉

---

<div class="post-metadata">

**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:** [Mars 1, 2021, 3:32 UTC](https://www.debian-fr.org/t/commande-sudo/84037/19 "2021-03-01T15:32:01Z")

</div>

> [@Zargos](#):
>
> Mais l’accès au disque qui est crypté ne sert à rien si on ne peut pas faire un rescue.

Pourquoi ?

> [@Zargos](#):
>
> sauf qu’on se retrouve avec le même problème avec le système minimal

Pas si le problème n’affecte que le système principal.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Mars 1, 2021, 3:34 UTC](https://www.debian-fr.org/t/commande-sudo/84037/20 "2021-03-01T15:34:44Z")

</div>

> [@PascalHambourg](#):
>
> Pas si le problème n’affecte que le système principal.

Certes, donc autant prévoir sur un disque séparé.

> [@PascalHambourg](#):
>
> > [@Zargos](#):
> >
> > Mais l’accès au disque qui est crypté ne sert à rien si on ne peut pas faire un rescue.
> 
> Pourquoi ?

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.

[Page suivante](https://www.debian-fr.org/t/commande-sudo/84037.md?page=2)
