Bonjour,
Puis-je savoir à quoi sert de désactiver le compte root si c'est pour
donner les pleins pouvoirs à un autre compte, en le dispensant de saisir
son mot de passe lorsqu'il utilise la commande sudo ?
echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
*>> Je pense avoir mal compris, je n'aurais pas du désactiver root, mais
seulement supprimer le mot de passe **pour ne pas conserver le hash du
mot de passe root en mémoire.
>> sudo passwd -d root*
*
*
*################################*
*################################
>> Il faudrait alors réactiver l'utilisateur root , pour qu'il puisse
gérer les tâches cron du système ( cron.daily ... ) :
>> sudo passwd --unlock root*
*>> Affiche :
>> passwd : déverrouiller le mot de passe créerait un compte sans mot
de passe.*
>> Vous devriez définir un mot de passe avec usermod -p pour
déverrouiller le mot de passe de ce compte.
>> passwd -S root
>> root L 2024-01-03 0 99999 7 -1
*>> Le compte reste verrouillé (L) après la commande passwd --unlock root*
>> *Définir un mot de passe avec usermod -p pour déverrouiller* le mot
de passe de ce compte (root)
*>> Il est indiqué dans une documentation d'enlever le mot de passe du
compte root pour ne pas laisser le hash en mémoire. :/
>> passwd root crérait / recrérait un compte root sans mot de passe ?
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>> Aucun hash de mot de passe ne serait alors conservé en mémoire et le
compte root serait utilisable par le système pour utiliser cron.
*
*################################
**################################*
Même si on interdit la connexion directe sous « root », ce qui peut se
concevoir,
*>>Oui, j'ai désactivé la connexion à root depuis SSH.
>> Il me semble qu'il faille le faire pour le système aussi ? # Sans
supprimer le compte root pour autant ? # C'est confus.*
il n’empêche que certaines commande doivent être lancées avec ces droits.
>> Effectivement.
du coup, pour modifier le crontab root, rien n’empêche d’utiliser un
sudo pour prendre ponctuellement ces droits pour modifier le crontab root.
*>> Oui il est possible de modifier la crontab root avec sudo crontab -e
>> Les tâches ne seront pas lancées et resteront en erreur
"Authentication failure" avec l'utilisateur root désactivé et le mot de
passe expiré.*
Dans le même sujet si une tâche n’a pas besoin des droits root rien
n’empêche d’utiliser un crontab « utilisateur » !
*>> Oui, il faut autoriser les scripts depuis "/etc/sudoers.d" mais les
tâches systèmes ( cron.daily ... ne sont pas lancées si l'utilisateur
root est désactivé. )*
>> sudo nano /etc/sudoers
>> Préférer le dossier "/etc/sudoers.d" : il sert à stocker des
fichiers déclaratifs pour sudoers qui seront lus en complément du
fichier sudoers.
>> Attention, tous les fichiers qui contiennent "~" ou "." dans le nom
ne seront pas lus !
>> Organiser les règles par fichier plutôt que de tout centraliser dans
le même fichier : le fichier sudoers sera toujours lu, dans tous les cas.
>> Pour créer un nouveau fichier nommé "amis_sh", on utilisera :
>> sudo visudo /etc/sudoers.d/amis_sh
>> sudo chmod 440 /etc/sudoers.d/amis_sh
*>> Ajouter deux ligne pour le script sudoer à autoriser :
>> amis_sh ALL=(ALL:ALL) ALL # Pas certain qu'il faille utiliser cette
ligne. J'ai testé sans, il me semble que cela ne fonctionne pas.
>> amis_sh ALL=(ALL) NOPASSWD:/home/amis_sh/test-crontab-sudo.sh*
>> nano test-crontab-sudo.sh
>> Ajouter les lignes suivantes :
>> !/bin/sh
>> touch "/home/amis_sh/test-crontab-sudo-ok1"; # Un fichier avec
droits utilisateur est créé.
>> su - amis_sh -c "touch test-crontab-sudo-user-ok"; # Un fichier avec
droits root est créé.
>> touch "/home/amis_sh/test-crontab-sudo-ok2"; # Un fichier avec
droits utilisateur est créé.
>> Utiliser la crontab de l'utilisateur : crontab -e
>> 55 12 * * * user=$(whoami) sudo /home/amis_sh/test-crontab-sudo.sh
>> updates.log 2>&1
Enfin, si on souhaite mieux gérer tout ça on peut utiliser /etc/cron.d
où on indique l’utilisateur à utiliser pour lancer la commande
souhaitée… mais il faut avoir les droits « root » pour créer cette
entrée ;-)
*>> Oui, Je suppose que l'on peut utiliser ici un nouvel utilisateur
gestionnaire avec les droits root.*
>> Le problème reste présent pour lancer les tâches cron.daily si
l'utilisateur root est désactivé.
Mention du paquet Debian super. https://packages.debian.org/trixie/super
paramétrable finement par /etc/super.tab
*>> Je n'ai pas regardé cette possibilité.*
>> Je lis pour les droits setuid :
# Elever les droits setuid sur les scripts exécutés par cron pour ne pas
avoir à utiliser sudo :
*>>* *Cette méthode pour ne pas utiliser sudo n'est pas recommandée* :
# sudo chown root script.sh
# sudo chmod 710 script.sh
# sudo chmod u+s script.sh
