sudo avec automation-cli

Pas d’artifice, utilisant une connexion SSH, au travers de laquelle on exécute un shell, il suffit de paramétrer sudo sur le serveur distant comme vous le souhaitez, et d’ajouter le commutateur -sudo à la commande “run”. Le shell sera exécuté dans ce mode.

Si vous devez passer un mot de passe, ajouter le commutateur -sudopass “valeur du mot de passe”.

Dans la pratique, il est fortement déconseillé de passer des mots de passe sur la ligne de commande. La méthode la plus sûre reste de paramétrer “sudo” sur le serveur distant, pour qu’il ne demande pas de mot de passe et de limiter la portée des commandes utilisées aux commandes indiquées dans l’opération. Ceci permet de bien contrôler ce qui est fait sur le serveur.

Un mot de passe peut être intercepté par n’importe quel moyen, si la portée n’est pas limitée, le mot de passe n’aura pas servi à “grand-chose”.

Limiter l’accès sudo à un mot de passe revient à donner l’accès root à l’utilisateur : sudo bash :)…

Préparation de l’environnement sudo

Sur l’hôte distant :

• Créer un compte utilisateur, ajouter pour ce compte :

  • La clé publique SSH liée à votre “OPSDirectory” (~/.ssh/authorized_keys).
  • Un mot de passe.

• Ajouter ce compte au groupe “sudo” (/etc/group).

À partir du nœud de contrôle dans un nouveau terminal, exécuter :

ssh -i [clé privée ssh OPSDirectory] [utilisateur]@[ip|nom hôte du serveur distant]
# vous êtes connecté à l'hôte, essayons une commande nécessitant les privilèges root
sudo cat /etc/shadow
# le shell demande le mot de passe utilisateur, saisir le mot de passe
# le shell affiche le contenu du fichier /etc/shadow

Exécution d’une opération, avec le mot de passe sudo utilisateur (mauvaise pratique)

À partir du nœud de contrôle, j’assume que la clé privée SSH est indiquée dans un fichier d’inventaire, exécuter :

export OPS="$(pwd)" # ou chemin relatif ou absolu OPSDirectory
automation-cli run -i "[chemin fichier d'inventaire]" -h "[ip|nom hôte du serveur distant]:[port SSH (22)]:[nom de l'utilisateur]" -c "cat /etc/shadow" -sudo -sudopass "[mot de passe de l'utilisateur]"

Le contenu du fichier est affiché, je répète : Ceci est une mauvaise pratique…

Exécution d’une opération, sans le mot de passe sudo utilisateur

Ceci nécessite un paramétrage “sudo” sur le nœud administré :

• 1ʳᵉ étape :

  • Retirer l’utilisateur du groupe “sudo”.
  • Editer le fichier /etc/sudoers avec la commande visudo, et ajouter après la ligne “root…” : [login utilisateur] ALL=(ALL) NOPASSWD: ALL
  • Exécuter :

  export OPS="$(pwd)" # ou chemin relatif ou absolu OPSDirectory
  automation-cli run -i "[chemin fichier d'inventaire]" -h "[ip|nom hôte du serveur distant]:[port SSH (22)]:[nom de l'utilisateur]" -c "cat /etc/shadow" -sudo"

  L’utilisateur n’a plus besoin de fournir son mot de passe, mais il bénéficie encore de tous les privilèges liés à cette mauvaise configuration de sudo.

• 2ᵉ étape :

  • Supprimer la ligne précédemment ajoutée au fichier /etc/sudoers
  • Créer le groupe “operation” et ajouter l’utilisateur à ce groupe (/etc/group)
  • indiquons la commandes autorisée (peut aussi être une liste) pour ce groupe :
    • Créer le fichier /etc/sudoers.d/operation :

    %operation ALL=(root) NOPASSWD: /usr/bin/cat /etc/shadow

    Attention les commandes autorisées doivent être définies avec leur chemin complet.

    export OPS="$(pwd)" # ou chemin relatif ou absolu OPSDirectory
    automation-cli run -i "[chemin fichier d'inventaire]" -h "[ip|nom hôte du serveur distant]:[port SSH (22)]:[nom de l'utilisateur]" -c "cat /etc/shadow" -sudo"

    L’utilisateur n’a toujours pas besoin de mot de passe, mais la liste des commandes utilisables est maintenant limitée, essayez en remplaçant cat par ls :

    export OPS="$(pwd)" # ou chemin relatif ou absolu OPSDirectory
    automation-cli run -i "[chemin fichier d'inventaire]" -h "[ip||nom hôte du serveur distant]:[port SSH (22)]:[nom de l'utilisateur]" -c "ls /etc/shadow" -sudo"

    sudo s’arrête pour demander le mot de passe de l’utilisateur, l’exécution est impossible. Essayez avec SSH, malgré le fait de fournir un mot de passe correct, sudo refusera d’exécuter cette dernière opération, parce que cette commande ne fait pas partie de la liste des commandes autorisées pour ce groupe.

• 3ᵉ étape :

  • Les opérations de type “operation” et “operationBook” entraîne la création d’un script bash, qui est envoyé sur le serveur distant dans le répertoire /tmp. Ce fichier est ensuite exécuté. En utilisant “sudo”, voici le paramétrage à effectuer :
  • En continuant avec l’exemple précédent, le fichier /etc/sudoers.d/operation doit ressembler à ceci :

    %operation ALL=(ALL) NOPASSWD: /usr/bin/bash /usr/bin/bash ^/tmp/[0-9]+A$, \
                                   /usr/bin/cat /etc/shadow

    ^/tmp/[0-9]+A$ : Ceci est la signature d’un fichier envoyé par automation-cli. J’ai laissé /usr/bin/cat... pour l’exemple.

Limiter l’action des utilisateurs au travers des outils d’automatisation peut devenir un vrai cauchemar (La documentation sudo)

Pour les systèmes durcis (OS hardening), l’exécution à partir de “/tmp” est bien souvent interdit (noexec), une implémentation de l’exécution pour ce type de cas est à l’étude.