Comment remplacer l'utilisateur root pour utiliser le service cron ?

[Bernard Bass]

Bonjour,

Voilà ma question : Comment remplacer l'utilisateur root pour utiliser le service cron ?

##############################################################################################################################
##############################################################################################################################

Utiliser cron et crontab sur Debian 12.
Un utilisateur sudoer est créé pour utiliser sudo et administrer le système.
L'utilisateur root a été désactivé sur le système Debian et le mot de passe est forcé pour expirer.

Des erreurs s'affichent dans journalctl, les tâches cron de l'utilisateur root ne sont pas lancées :

SERVEUR cron : Authentication failure
Password root of that user should be expried.

Le compte utilisateur root est verrouillé et le mot de passe est forcé pour expirer, il ne peut être utilisé pour lancer des tâches cron.

COMMENT CREER UN UTILISATEUR POUR REMPLACER ROOT ET UTILISER SA CRONTAB ?

Créer un utilisateur pour remplacer root :
sudo adduser gestionnaire
sudo bash
echo "gestionnaire ALL=(ALL) ALL" >> /etc/sudoers
echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

Ajouter gestionnaire au groupe cron :
gpasswd -a gestionnaire cron

Lorsque un utilisateur est ajouté au groupe cron, se déconnecter et se reconnecter pour rendre l'ajout au groupe effectif.

Comment faire comprendre au système qu'il faut utiliser le nouvel utilisateur pour lancer les tâches cron du système ?

( la crontab de l'utilisateur sudoer, la crontab de l'utilisateur gestionnaire, les tâches cron.daily ..... , les tâches des services dans le dossier cron.d )

##############################################################################################################################
##############################################################################################################################

La recherche actuelle :

( Les tâches cron.daily ..... , les tâches des services dans le dossier cron.d ne fonctionnent pas " cron : Authentication failure " )

##############################################################################################################################

Utiliser cron et crontab sur Debian 12.
Un utilisateur sudoer est créé pour utiliser sudo et administrer le système.

L'utilisateur root a été désactivé sur le système Debian et le mot de passe est forcé pour expirer.

Des erreurs s'affichent dans journalctl, les tâches cron de l'utilisateur root ne sont pas lancées.

##############################################################################################################################

sudo journalctl -p err
févr. 11 16:25:01 SERVEUR CRON[874565]: pam_unix(cron:account): account root has expired (account expired)
févr. 11 16:25:01 SERVEUR cron[874565]: Authentication failure <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
sudo[874537]: pam_unix(sudo:session): session closed for user root

Le compte utilisateur root est verrouillé et ne peut être utilisé pour lancer des tâches cron.
Password root of that user should be expried. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

##############################################################################################################################

COMMENT CREER UN UTILISATEUR ROOT POUR REMPLACER ROOT ET UTILISER SA CRONTAB ? <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Comment exécuter une commande exigeant un plus haut niveau de permission (root ou racine) ?


Créer un utilisateur pour remplacer root :
sudo adduser gestionnaire
sudo bash
echo "gestionnaire ALL=(ALL) ALL" >> /etc/sudoers
echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

Ajouter gestionnaire au groupe cron :
gpasswd -a gestionnaire cron
Lorsque un utilisateur est ajouté au groupe cron, se déconnecter et se reconnecter pour rendre l'ajout au groupe effectif.

Comment faire comprendre au système qu'il faut utiliser gestionnaire pour lancer les tâches cron ?
...
...


##############################################################################################################################

sudo systemctl stop cron
sudo systemctl start cron
sudo systemctl restart cron

# Identifier les processus cron :
sudo systemctl status cron
# Arrêter un processus cron :
sudo kill PID

##############################################################################################################################

# Afficher le crontab de l'utilisateur courant :
crontab -l

# Editer le crontab de l'utilisateur courant :
crontab -e

# Editer le crontab de l'utilisateur root :
sudo crontab -e

# Modifier la crontab d'un autre utilisateur :
sudo crontab -e -u nom_utilisateur

##############################################################################################################################

# Définir un éditeur de commandes pour éditer les crontabs :
sudo update-alternatives --config editor
# Ou :
select-editor
# Ou :
export EDITOR=/usr/bin/nano

##############################################################################################################################

Une tâche cron est exécutée dans un shell non connecté (non-login) et non interactif. Les variables d'environnement habituelles et en particulier PATH ne sont pas connues.
Il faut donc soit mettre les emplacements complets des exécutables dans les commandes et les scripts appelés par cron, soit définir PATH dans le fichier crontab :
Exemple :
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

Exemple :
SHELL=/bin/bash
PATH=/home/USER/bin:/usr/local/bin:/usr/bin
MAILTO=ma...@domain.ext

##############################################################################################################################

Afficher les règles cron de l'utilisateur root avec sudo :
sudo crontab -e
L'utilisateur root peut utiliser le fichier /etc/crontab ou le répertoire /etc/cron.d/ pour ajouter des tâches, en précisant le nom d'utilisateur root.

##############################################################################################################################

# Lister les tâches cron planifiées sur le système depuis les dossiers suivants :

/etc/cron.hourly/

cd cron.daily/
/etc/cron.daily# ls
00logwatch  apache2  apt-compat  automysqlbackup  clamav  dpkg    exim4-base  locate  logrotate  man-db <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

/etc/cron.weekly# ls -la
ls -la
total 16
drwxr-xr-x  2 root root 4096 12 juil.  2023 .
drwxr-xr-x 89 root root 4096 17 févr. 18:35 ..
-rwxr-xr-x  1 root root 1055 12 mars   2023 man-db <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
-rw-r--r--  1 root root  102  2 mars   2023 .placeholder

/etc/cron.monthly

/etc/cron.yearly

##############################################################################################################################

# Contrairement aux lignes d'un fichier crontab, les fichiers suivants doivent préciser quel utilisateur exécute le script :
# * * * * * nom_utilisateur /bin/touch /path/fichier
cd /etc/cron.d <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
ls -la
-rw-r--r--  1 root root  802 16 avril  2023 certbot
-rw-r--r--  1 root root  695  2 janv.  2021 clamav-unofficial-sigs
-rw-r--r--  1 root root  201  5 mars   2023 e2scrub_all
-rw-r--r--  1 root root  712 13 juil.  2022 php
-rw-r--r--  1 root root  102  2 mars   2023 .placeholder
-rw-r--r--  1 root root  163  4 sept. 15:18 sync

##############################################################################################################################

# SHELL est le shell dans lequel sera executé cron.
# Si ce dernier n'est pas spécifié, l'entrée de l'utilisateur sera prise par défaut dans le fichier /etc/passwd :
cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
...

HOME est le répertoire home de cron. (???) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Si aucun n'est spécifiée, ce sera l'entrée de /etc/passwd qui sera utilisée. (???)

##############################################################################################################################

# Editer avec root le fichier /etc/group :
sudo nano /etc/group

# Ajouter un utilisateur autorisé à utiliser cron dans le group crontab :
crontab:x:101:amis_sh 

( Je n'ai pas encore ajouté l'utilisateur gestionnaire. )

##############################################################################################################################

Tout utilisateur que vous souhaitez pouvoir exécuter des tâches cron doit être répertorié dans /etc/cron.allow (un utilisateur par ligne).
Si le fichier cron.allow n’existe pas, mais que le fichier /etc/cron.deny existe, alors l'utilisateur ne doit pas y être répertorié.
nano /etc/cron.allow
Ajouter amis_sh

Dans le cas où les deux fichiers n'existent pas, seul l'utilisateur root est éligible pour exécuter des tâches cron.

Lister les utilisateurs et leur crontabs :
cd /var/spool/cron/crontabs
ls
amis_sh  root

Vérifier les droits du fichier /var/spool/cron/crontabs/amis_sh
cd /var/spool/cron/crontabs/
ls -la
-rw------- 1 amis_sh crontab 1714 11 févr. 22:35 amis_sh
-rw------- 1 root    crontab  922 11 févr. 16:38 root

##############################################################################################################################

Pour executer un script avec sudo sans avoir à donner le mot de passe :
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
amis_sh ALL=(ALL) NOPASSWD:/home/amis_sh/test-crontab-sudo.sh
### amis_sh ALL=(root) NOPASSWD: /home/amis_sh/test-crontab-sudo.sh

Note: in sudoers, the last match wins.

40 18 11 2 * sudo ./test-crontab-sudo.sh >> updates.log 2>&1

chmod +x /home/amis_sh/test-crontab-sudo.sh

##############################################################################################################################

# Exemple de la crontab de l'utilisateur amis-sh :

crontab -e

###################################################
# Sauvegarder les règles de l'utilisateur amis_sh par mail :
# sudo bash
# mailx -a /var/spool/cron/crontabs/amis_sh -s "/var/spool/cron/crontabs/amis_sh" ma...@domain.ext < /var/spool/cron/crontabs/amis_sh

###################################################
###################################################
# Tester crontab
###################################################
###################################################
# Créer un fichier test-crontab.sh :
# nano test-crontab.sh
#!/bin/sh
#touch "/home/amis_sh/crontab-script-sh-ok";
###################################################

###################################################
# nano test-crontab-sudo.sh
#!/bin/sh
#touch "/home/amis_sh/test-crontab-sudo-ok1";
#su - amis_sh -c "touch test-crontab-sudo-user-ok";
#touch "/home/amis_sh/test-crontab-sudo-ok2";
###################################################

###################################################
# Les actions suivantes fonctionnent pour l'utilisateur amis_sh :
# Mois février jour 11 à 17h 58m.

# Créer directement un fichier user :
# 03 19 11 2 * touch /home/amis_sh/crontab-ok

# Créer un fichier user depuis un script :
# 03 19 11 2 * /home/amis_sh/test-crontab.sh

# Créer deux fichier user et un fichier root et un fichier de log depuis un script :
# 22 21 11 2 * user=$(whoami) sudo /home/amis_sh/test-crontab-sudo.sh >> updates.log 2>&1
###################################################
###################################################

##############################################################################################################################

# Tester au démarrage de la session ssh :
# /home/amis_sh/test-crontab-sudo.sh

##############################################################################################################################

# Cette méthode pour ne pas utiliser sudo n'est pas recommandée :
# Elever les droits setuid sur les scripts exécutés par cron pour ne pas avoir à utiliser sudo :
# sudo chown root script.sh
# sudo chmod 710 script.sh
# sudo chmod u+s script.sh

##############################################################################################################################

Fichiers de configuration de dpkg et cron :

cat /var/lib/dpkg/info/cron.conffiles
/etc/cron.d/.placeholder
/etc/cron.daily/.placeholder
/etc/cron.hourly/.placeholder
/etc/cron.monthly/.placeholder
/etc/cron.weekly/.placeholder
/etc/crontab
/etc/default/cron
/etc/init.d/cron
/etc/pam.d/cron

##############################################################################################################################

# Exemples de tâches cron :

01 * * * * root echo "cette commande est exécutée toutes les heures passées d'une minute"
17 8 * * * root echo "Cette commande est exécutée tous les jours à 08h17"
17 20 * * * root echo "Cette commande est exécutée tous les jours à 20h17"
00 4 * * 0 root echo "Cette commande est exécutée tous les dimanches à 4h00"
42 4 1 * * root echo "Cette commande est exécutée tous les 1er du mois à 4h42"
01 * 19 07 * root echo "Cette commande est exécutée toutes les heures passées d'une minute tous les 19 Juillet"

# Mise à jour de locate chaque premier du mois :
22 2 * * 1    /usr/bin/updatedb

# Provoquer un reboot la machine chaque 1er et 15 du mois à 2h 30 du matin :
30 2  1,15 * * /sbin/shutdown -r

# Appeler un script de sauvegarde tous les lundis a 3 h 15 du matin :
15  3  *  * 1 /usr/bin/backup

# Exécution tous les quarts d'heure de 15h à 19h du lundi au vendredi seulement en 1ère quinzaine du troisième trimestre :
0,15,30,45  15-19  1-15  7-9  1-5 <commande>

# Trouver puis nettoyer le répertoire /tmp des vieux fichiers (non modifiés depuis 31 jours) tous les 1er jour de chaque mois, à 2 heures du matin :
0 2 1 * * find /tmp -atime 31 -exec rm -f {} \;

# Faire apparaitre un message dans la GUI d'un utilisateur à une heure précice
50 18 * * * export DISPLAY=localhost:0.0; xhost + | zenity --info --text="Reboot de l'ordinateur dans 10min, penser à faire vos sauvegardes"

# Exécution tous les jours à 22h00 d'une commande et rediriger les infos dans sauvegarde.log :
00 22 * * * /root/scripts/sauvegarde.sh >> sauvegarde.log


# Vous pouvez rediriger la sortie (par exemple vers /dev/null si vous n’en voulez vraiment pas ) ou dans un fichier de log en utilisant la syntaxe suivante :
cmd >> log.file

# Ceci redirige la sortie standard et non les erreurs, pour rediriger les erreurs, vous devez utiliser la syntaxe suivante :
cmd >> logfile 2>&1

Exécuter une commande au démarrage. Pour exécuter une commande une seule fois, juste après le démarrage de l'ordinateur, on peut recourir à la macro @reboot (un simple redémarrage de cron ne déclenche pas une commande planifiée avec @reboot). Cette macro remplace elle aussi les cinq premiers champs d'une entrée dans la crontab.

@yearly : une fois par an (le premier janvier à 0 h 00) ;
@monthly : une fois par mois (le premier du mois à 0 h 00) ;
@weekly : une fois par semaine (le dimanche à 0 h 00) ;
@daily : une fois par jour (à 0 h 00) ;
@hourly : une fois par heure (au début de chaque heure).

##############################################################################################################################

# Pour lister les scripts dans /etc/cron.d utiliser :
cat /etc/cron.d/* | grep "certbot (Mot clé)"


# Lister les tâches cron par utilisateurs du fichier /etc/passwd.
for user in $(cut -f1 -d: /etc/passwd); do echo -e "\n\n==> $user:" && crontab -u $user -l; done


# Ce script ne fonctionne pas sur les crons périodiques (cron.daily, cron.weekly, etc.) qui sont dans des répertoires distincts et non liés à un utilisateur mais au système !
# Lister tous les scripts sans le contenu :
ls -al /etc/cron.*

-rw-r--r-- 1 root root    8 11 févr. 18:13 /etc/cron.allow

/etc/cron.d:
total 32
drwxr-xr-x  2 root root 4096  8 févr. 20:06 .
drwxr-xr-x 89 root root 4096 17 févr. 22:03 ..
-rw-r--r--  1 root root  802 16 avril  2023 certbot
-rw-r--r--  1 root root  695  2 janv.  2021 clamav-unofficial-sigs
-rw-r--r--  1 root root  201  5 mars   2023 e2scrub_all
-rw-r--r--  1 root root  712 13 juil.  2022 php
-rw-r--r--  1 root root  102  2 mars   2023 .placeholder
-rw-r--r--  1 root root  163  4 sept. 15:18 sync

/etc/cron.daily:
total 56
drwxr-xr-x  2 root root 4096 11 févr. 22:22 .
drwxr-xr-x 89 root root 4096 17 févr. 22:03 ..
-rwxr-xr-x  1 root root  268  4 oct.   2020 00logwatch
-rwxr-xr-x  1 root root  539  9 juin   2022 apache2
-rwxr-xr-x  1 root root 1478 25 mai    2023 apt-compat
-rwxr-xr-x  1 root root   80 30 août   2021 automysqlbackup
-rw-r--r--  1 root root  535 11 févr. 22:22 clamav
-rwxr-xr-x  1 root root  123 27 mars   2023 dpkg
-rwxr-xr-x  1 root root 4722 29 sept. 22:38 exim4-base
-rwxr-xr-x  1 root root 2211 10 févr.  2018 locate
-rwxr-xr-x  1 root root  377 14 déc.   2022 logrotate
-rwxr-xr-x  1 root root 1395 12 mars   2023 man-db
-rw-r--r--  1 root root  102  2 mars   2023 .placeholder

/etc/cron.hourly:
total 12
drwxr-xr-x  2 root root 4096 12 juil.  2023 .
drwxr-xr-x 89 root root 4096 17 févr. 22:03 ..
-rw-r--r--  1 root root  102  2 mars   2023 .placeholder

/etc/cron.monthly:
total 12
drwxr-xr-x  2 root root 4096 12 juil.  2023 .
drwxr-xr-x 89 root root 4096 17 févr. 22:03 ..
-rw-r--r--  1 root root  102  2 mars   2023 .placeholder

/etc/cron.weekly:
total 16
drwxr-xr-x  2 root root 4096 12 juil.  2023 .
drwxr-xr-x 89 root root 4096 17 févr. 22:03 ..
-rwxr-xr-x  1 root root 1055 12 mars   2023 man-db
-rw-r--r--  1 root root  102  2 mars   2023 .placeholder

/etc/cron.yearly:
total 12
drwxr-xr-x  2 root root 4096 12 juil.  2023 .
drwxr-xr-x 89 root root 4096 17 févr. 22:03 ..
-rw-r--r--  1 root root  102  2 mars   2023 .placeholder

##############################################################################################################################

# Sauvegarder les fichiers crontab de tous les utilisateurs présents dans le fichier /etc/passwd vers un fichier /root/crontab :
for user in $(cut -f1 -d: /etc/passwd); do echo -e "\n\n==> $user:" ; crontab -u $user -l ; done > /root/crontab 2>&1

##############################################################################################################################

[Sébastien Dinot]

Bernard Bass a écrit :

> Voilà ma question : Comment remplacer l'utilisateur root pour utiliser
> le service cron ?

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

La subtilité de la manœuvre m'échappe.

Sébastien

--
Sébastien Dinot, sebasti...@free.fr
http://www.palabritudes.net/
Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer !

[Pierre Malard]

Bonjour,

Même question, tout ça sert-il à quoi que ce soit ?

Même si on interdit la connexion directe sous « root », ce qui peut se concevoir, il n’empêche que certaines commande doivent être lancées avec ces droits. su coup, pour modifier le crontab root, rien n’empêche d’utiliser un sudo pour prendre ponctuellement ces droits pour modifier le crontab root.

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

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

https://doc.ubuntu-fr.org/cron

-- 

Pierre Malard

Responsable architectures système CDS DINAMIS/THEIA Montpellier

IRD - UMR Espace-Dev - UAR CPST - IR Data-Terra

Maison de la Télédétection

500 rue Jean-François Breton

34093 Montpellier Cx 5

France

Tél : +33 626 89 22 68

   «[...]développer la science ? Noble ambition ; mais qu'est-ce que 

    la science ? Une puissance et une joie ; et, si elle ne s'anime pas 

   de l'esprit de justice, [...] de la vie des hommes, [...] elle est un

   privilège en plus.»

Jean Jaures - "L'idéal de justice" - 1889

   |\      _,,,---,,_

   /,`.-'`'    -.  ;-;;,_

  |,4-  ) )-,_. ,\ (  `'-'

 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'

- --> Ce message n’engage que son auteur <--

[Basile Starynkevitch]

On 2/18/24 09:26, Pierre Malard wrote:
> Bonjour,
>
> Même question, tout ça sert-il à quoi que ce soit ?
>
> Même si on interdit la connexion directe sous « root », ce qui peut se
> concevoir, il n’empêche que certaines commande doivent être lancées
> avec ces droits. su coup, pour modifier le crontab root, rien
> n’empêche d’utiliser un sudo pour prendre ponctuellement ces droits
> pour modifier le crontab root.

Tout à fait d'accord.

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

D'accord aussi.

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

Et j'ajouterais la mention du paquet Debian super.
https://packages.debian.org/trixie/super paramétrable finement par
/etc/super.tab


--
Basile Starynkevitch <bas...@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
See/voir: https://github.com/RefPerSys/RefPerSys

[Bernard Bass]

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 :

[Pierre Malard]

Bonjour,

Le 18 févr. 2024 à 18:46, Bernard Bass <bernar...@visionduweb.com> a écrit :

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

J’ai du louper des épisodes car je ne vois nulle part dans les réponses faites une mention laissant entendre qu’il fallait « disposer [l’utilisateur] de saisir son mot de passe ». C’est, à mon sens, une très mauvaise pratique à  moins de limiter drastiquement les commandes laissées à cet usage.

-- 
Pierre Malard

   «Il vaut mieux passer à La Poste qu’à la postérité»
                                                  Alphonse Allais

   |\      _,,,---,,_

[Bernard Bass]

Pour protéger l'accès au compte root, j'ai bien configuré sshd pour interdire le user root, la connexion par mot de passe vide et par mot de passe, uniquement autoriser la connexion par clé ssh ed25519.

sudo passwd root # Créer un mot de passe.
passwd --lock root # Le compte root est alors à nouveau verrouillé !
sudo passwd -S root
[sudo] Mot de passe de l'utilisateur sudoers :
root L 12/23/2019 0 99999 7 -1 # Le compte root est verrouillé.


sudo passwd root # Créer un mot de passe.
sudo passwd -d root
passwd : informations de validité du mot de passe changées.
sudo passwd -S root
root NP 02/18/2024 0 99999 7 -1
# Le compte root est accessible sans mot de passe depuis l'utilisateur sudoers ( Et même d'un simple utilisateur ? Si il a les clés ssh pour se connecter au serveur.).
$ su root # Aucun mot de passe n'est demandé pour passer à l'utilisateur root.
#


Il semble donc nécessaire de définir un mot de passe complexe pour root et de laisser l'utilisateur root activé.
Je ne comprend pas la méthode pour désactiver l'utilisateur root, ou le mot de passe de l'utilisateur root, en restant dans la bonne pratique de sécurité, tout en lui laissant la possibité d'administrer cron.'
Supprimer le mot de passe de l'utilisateur root pour ne pas conserver le hash du mot de passe en mémoire.

Désactiver l'utilisateur root à partir du shell :
Le moyen le plus simple de désactiver la connexion de l'utilisateur root est de changer son shell du répertoire /bin/bash à /sbin/nologin, dans le fichier
Par défaut :

root:x:0:0:root:/root:/bin/bash

Si la valeur est changée pour /sbin/nologin , root sera t'il encore capable d'administrer le système ? ( Tâches cron et autres tâches ? )
sudo nano /etc/passwd
root:x:0:0:root:/root:/sbin/nologin

su root
This account is currently not available.

sudo bash
root@system

sudo crontab -e
Ajouter une tâche.

Erreurs :

Après avoir désactivé root sur le système, je ne vois pas de solution qui permet aux taches cron root, ou cron.daily de fonctionner sans configurations avancées.
Aucun répertoire /lib/security sur ma machine :

févr. 18 20:16:02 system sudo[11786]: PAM unable to dlopen(pam_ck_connector.so): /lib/security/pam_ck_connector.so: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce nom
févr. 18 20:16:02 system sudo[11786]: PAM adding faulty module: pam_ck_connector.so
févr. 18 20:17:01 system CRON[11802]: PAM unable to dlopen(pam_ck_connector.so): /lib/security/pam_ck_connector.so: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce nom
févr. 18 20:17:01 system CRON[11802]: PAM adding faulty module: pam_ck_connector.so

[Bernard Bass]

La solution fonctionnelle pour désactiver root semble être la suivante :


1)

sudo passwd root # Créer un mot de passe.

sudo passwd -d root # Supprimer le mot de passe.

2)
* Désactiver l'utilisateur root à partir du shell.
Le moyen le plus simple de désactiver la connexion de l'utilisateur root est de changer son shell du répertoire /bin/bash à /sbin/nologin, dans le fichier /etc/passwd.

sudo nano /etc/passwd
root:x:0:0:root:/root:/sbin/nologin

3)
sudo passwd -S root
root NP 02/18/2024 0 99999 7 -1 # L'utilisateur root utilise no password.

4)

su root
This account is currently not available.

5)
On ne peut donc pas accéder à root directement.
Le système cron avec la crontab -e root continue de fonctionner.
Le user root semble faire son travail sans erreur.



J'aurais préféré créer un utilisateur gestionnaire pour remplacer les actions de l'utilisateur root, capable de lancer toutes les tâches cron.
Si quelqu'un sait expliquer la méthode.
Merci.

[Bernard Bass]

Bonsoir,

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

J’ai du louper des épisodes car je ne vois nulle part dans les réponses faites une mention laissant entendre qu’il fallait « disposer [l’utilisateur] de saisir son mot de passe ». C’est, à mon sens, une très mauvaise pratique à  moins de limiter drastiquement les commandes laissées à cet usage.

Effectivement.
Je n'ai pas la méthode pour créer un utilisateur root.
J'ai des notes pour créer un sudoer dans le groupe sudo.
Je ne sais par contre pas s'il est possible de créer un utilisateur semblable à l'utilisateur root.
On m'avait surement déjà répondu, cela n'est probablement pas possible, ou, compliqué, puisque c'est root (0) qui administre le système.

J'ai passé root en /sbin/nologin dans /etc/passwd ce qui empêche l'utilisation de root, tout en permettant au système de fonctionner, sudo crontab -e fonctionne normalement.

Je ne sais toujours pas créer un utilisateur gestionnaire capable de prendre le rôle de root, pour faire fonctionner l'ensemble des services cron, sans passer par des manipulations complexes.

Merci d'avoir répondu.

[Pierre Malard]

Bonjour,

Franchement je ne comprends pas bien ces « modèles ». Soit avoir un login « super administrateur », root ou non, vous donne des bougons et, dans ce cas bloquez tout login direct acec un « x » dans le champ password du fichier /etc/shadow.  Une méthode plus propre :

$ sudo usermod -L root

Cela ajoute un « ! » devant le mot de passe haché.

Cela n’empêche pas un login « root » avec SSH par échange de clé. Mais il faut avoir, au préalable, ajouter ces clés publiques sur le compte root ce qui est difficile sans une connexion sur le serveur.

Si vous ne voulez pas de connexion SSH directe possible, interdisez le dans un complément de ssh_config dans /etc/ssh/sshd_config.d/TOTO.conf avec :

PermitRootLogin No

DenyUsers root@*

Par exemple (même si la première ligne devrait suffire…)

Pour ce qui est du login, vous en avez besoin pour administrer. Ce n’est donc pas une discussion.

À partir de là le seul moyen d’accéder aux droits « root » est de passer par un utilisateur sudoer pour lancer un « sudo commande » sans bloquer le système pour autant.

Si vous vous méfiez des éventuels utilisateurs sudoer vous pouvez limiter les commandes possibles pour eux dans la configuration de sudoer. Allez faire un tour à la fin de https://www.malekal.com/exemples-sudoers-configurer-sudo-linux/

-- 

Pierre Malard

   « La vérité ne triomphe jamais, mais ses ennemis finissent

    toujours par mourir... »

                                                   Max Placnk (1858-1947)

   |\      _,,,---,,_

[k6de...@free.fr]

Bonjour,
Je découvre ce fil de discussion.
Je ne comprends pas que l'on puisse encore travailler avec CRON.
Alors que ANACRON est indépendant de la période de fonctionnement du PC.

Peut-etre que vous pourriez trouver une piste de solution dans l'article de Léa Linux espliquant les fonctionalités de at, cron et anacron.
https://lea-linux.org/documentations/Programmation_de_travaux_avec_at_cron_anacron

Bon courage
Cassis


----- Mail d'origine -----
De: Bernard Bass <bernar...@visionduweb.com>
À: Liste Debian <debian-us...@lists.debian.org>
Envoyé: Sun, 18 Feb 2024 00:32:25 +0100 (CET)
Objet: Comment remplacer l'utilisateur root pour utiliser le service cron ?

Bonjour,

Voilà ma question : Comment remplacer l'utilisateur root pour utiliser
le service cron ?

##############################################################################################################################
##############################################################################################################################

Utiliser cron et crontab sur Debian 12.
Un utilisateur sudoer est créé pour utiliser sudo et administrer le système.

*L'utilisateur root a été désactivé sur le système Debian et le mot de
passe est forcé pour expirer.*

Des erreurs s'affichent dans journalctl, les tâches cron de
l'utilisateur root ne sont pas lancées :

*SERVEUR cron : Authentication failure
Password root of that user should be expried.*

Le compte utilisateur root est verrouillé et le mot de passe est forcé
pour expirer, il ne peut être utilisé pour lancer des tâches cron.

*COMMENT CREER UN UTILISATEUR POUR REMPLACER ROOT ET UTILISER SA CRONTAB ?*

Créer un utilisateur pour remplacer root :
sudo adduser gestionnaire
sudo bash
echo "gestionnaire ALL=(ALL) ALL" >> /etc/sudoers
echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

Ajouter gestionnaire au groupe cron :
gpasswd -a gestionnaire cron

Lorsque un utilisateur est ajouté au groupe cron, se déconnecter et se
reconnecter pour rendre l'ajout au groupe effectif.

*Comment faire comprendre au système qu'il faut utiliser le nouvel
utilisateur pour lancer les tâches cron du système ?*

*( la crontab de l'utilisateur sudoer, la crontab de l'utilisateur

gestionnaire, les tâches cron.daily ..... , les tâches des services dans
le dossier cron.d )

*

##############################################################################################################################
##############################################################################################################################






La recherche actuelle :

*( Les tâches cron.daily ..... , les tâches des services dans le dossier
cron.d ne fonctionnent pas **" cron **: **Authentication failure " **)
*

##############################################################################################################################

Utiliser cron et crontab sur Debian 12.
Un utilisateur sudoer est créé pour utiliser sudo et administrer le système.

L'utilisateur root a été désactivé sur le système Debian et le mot de
passe est forcé pour expirer.

Des erreurs s'affichent dans journalctl, les tâches cron de
l'utilisateur root ne sont pas lancées.

##############################################################################################################################

sudo journalctl -p err
févr. 11 16:25:01 SERVEUR CRON[874565]: pam_unix(cron:account): account
root has expired (account expired)

*févr. 11 16:25:01 SERVEUR cron[874565]: Authentication failure
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<*

sudo[874537]: pam_unix(sudo:session): session closed for user root

Le compte utilisateur root est verrouillé et ne peut être utilisé pour
lancer des tâches cron.

*Password root of that user should be expried.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<*

##############################################################################################################################

*COMMENT CREER UN UTILISATEUR ROOT POUR REMPLACER ROOT ET UTILISER SA
CRONTAB ? <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<*

Comment exécuter une commande exigeant un plus haut niveau de permission
(root ou racine) ?


Créer un utilisateur pour remplacer root :
sudo adduser gestionnaire
sudo bash
echo "gestionnaire ALL=(ALL) ALL" >> /etc/sudoers
echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

Ajouter gestionnaire au groupe cron :
gpasswd -a gestionnaire cron
Lorsque un utilisateur est ajouté au groupe cron, se déconnecter et se
reconnecter pour rendre l'ajout au groupe effectif.

*Comment faire comprendre au système qu'il faut utiliser gestionnaire
pour lancer les tâches cron ?*

[NoSpam]

Bonjour

Le 20/02/2024 à 05:54, k6de...@free.fr a écrit :
> Bonjour,
> Je découvre ce fil de discussion.
> Je ne comprends pas que l'on puisse encore travailler avec CRON.
> Alors que ANACRON est indépendant de la période de fonctionnement du PC.

Si on se place d'un point de vue poste de travail. Pour les serveurs,
aucun intérêt !

[Bernard Bass]

La question initiale : Comment remplacer l'utilisateur root pour utiliser le service cron ?

Devrait plutôt être : Comment lancer le service cron/crontab avec l'utilisateur gestionnaire (root) ?

J'ai créé l'utilisateur gestionnaire de la sorte :

Créer un utilisateur gestionnaire pour remplacer les actions de l'utilisateur root, pour lancer toutes les tâches cron.

Consulter les groupes de l'utilisateur root :
sudo bash
id
uid=0(root) gid=0(root) groupes=0(root)

groups
root

Créer l'utilisateur gestionnaire :
sudo adduser gestionnaire

Ajouter l'utilisateur gestionnaire au groupe des administrateurs système (root) à l'aide de la commande usermod :
# usermod -aG sudo gestionnaire
sudo usermod -aG root gestionnaire

Ajouter les droits root à l'utilisateur gestionnaire avec visudo :
sudo visudo
root    ALL=(ALL:ALL) ALL
gestionnaire    ALL=(ALL:ALL) ALL

sudo bash
cat /etc/passwd | grep -i gestionnaire
gestionnaire:x:1001:1001:,,,:/home/gestionnaire:/bin/bash

sudo bash
Donner à l'utilisateur gestionnaire les privilèges root sans qu'il n'ait a utiliser sudo :
Changer l'ID de l'utilisateur gestionnaire avec l'option d'ID utilisateur non unique :
usermod -o -u 0 gestionnaire

Utiliser su pour s'identifier avec l'utilisateur gestionnaire et devenir root :
$ su gestionnaire
Mot de passe :
root@system:/home/utilisateur-courant#

cat /etc/passwd | grep -i gestionnaire
gestionnaire:x:0:1001:,,,:/home/gestionnaire:/bin/bash

La ligne peut être réécrite de la façon suivante :
sudo nano /etc/passwd
gestionnaire:x:0:1001:Gestionnaire:/home/gestionnaire:/bin/bash

Je n'ai pas trouvé comment relancer le service cron avec cet autre utilisateur gestionnaire.

[Christophe Maquaire]

Y'a même mieux ou pire, c'est selon:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

Comme debian est passé à systemd, autant en profiter ou boire le calice
jusqu'à la lie, c'est encore selon.

Christophe

[Christophe Maquaire]

Le mardi 20 février 2024 à 11:19 +0100, Christophe Maquaire a écrit :
>
>
> Y'a même mieux ou pire, c'est selon:
>
> https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

Je continue le prosélytisme:
In French et illustré par
l'exemple:https://wiki.archlinux.org/title/Systemd_(Fran%C3%A7ais)/Timers_(Fran%C3%A7ais)

Christophe

[Bernard Bass]

L'utilisateur gestionnaire est créé.

Identifier l'utilisateur qui fait tourner le service cron :
ps -Af | grep cron
root         890       1  0 20:21 ?        00:00:00 /usr/sbin/cron -f -P

sudo systemctl stop cron

cd /usr/sbin/
ls -la
-rwxr-xr-x  1 root root     51792 mars  23  2022 cron

sudo bash
chown gestionnaire:gestionnaire cron
cd /usr/sbin/
ls -la
-rwxr-xr-x  1 root gestionnaire   51792 mars  23  2022 cron

sudo systemctl restart cron

ps -Af | grep cron
root        5315       1  0 20:38 ?        00:00:00 /usr/sbin/cron -f -P

C'est toujours l'utilisateur root qui fait tourner le service cron.
L'ID de l'utilisateur gestionnaire avec l'option d'ID utilisateur non unique est 0 (root).