Autoriser l'exécution automatique de commandes en tant que root sous Linux à l'aide de SSH

Je pense qu'une solution appropriée pour la majorité des cas simples [c'est-à-dire si un framework comme Puppet/Chef/CfEngine/Ansible est exagéré], mais un haut niveau de contrôle du système distant est requis est de

(a) Exiger une authentification basée sur une clé(b) verrouiller les emplacements qui peuvent être utilisés par SSH - en particulier pour verrouiller les adresses IP que les utilisateurs root peuvent utiliser(c) S'assurer que les machines avec cette relation de confiance sont correctement sécurisées.

Je ne crois pas que "se connecter en tant que root soit mal vu", autant que "se connecter en tant que root pour faire des choses qui ne nécessitent pas d'autorisations root" soit mal vu. Avoir un mot de passe devinable permet au compte d'être brutalement forcé, c'est donc un problème à gérer, et en permettant aux gens de se connecter en tant que root, ils peuvent faire des erreurs stupides avec une portée plus large et faire des choses douteuses qui cachent activité malveillante - mais selon l'architecture, cela peut ne pas être significatif.

Cette bande dessinée XKCD souligne qu'en fonction de l'environnement, le fait qu'un compte root soit compromis peut ne pas avoir d'importance.

La solution la plus simpliste et la plus efficace pour le cas général est probablement de limiter exactement qui peut se connecter en tant que root en contrôlant les clés en conjonction avec la spécification d'une ligne AllowUsers appropriée dans /etc/ssh/sshd.conf. Une ligne appropriée pour autoriser les utilisateurs normaux mais verrouiller l'accès root pourrait ressembler à :

  AllowUsers normaluser1 normaluser2 [email protected]

Bien sûr, il est important que la connexion basée sur un mot de passe ne soit pas autorisée, ou que le compte root n'ait pas de mot de passe (c'est-à-dire qu'il ait un "!" ou "*" dans le champ mot de passe du fichier de mot de passe.)

Comme vous l'avez postulé, si un seul programme (ou un petit nombre de) doit être exécuté, vous feriez peut-être mieux de configurer un utilisateur spécifique avec une authentification basée sur une clé et d'autoriser un accès sudo approprié aux commandes requises.

Il y a, bien sûr, beaucoup de choses qui peuvent être faites pour "verrouiller" davantage l'accès, en fonction de la valeur des données - selinux, journalisation à distance, shell limité, contraintes d'heure du jour, notifications immédiates sur les connexions , la surveillance active des journaux comme fail2ban [en plus des restrictions réseau que je considère comme non facultatives] peuvent toutes faire partie d'une solution. Cela dit, si vous contrôlez simplement un système qui peut être détruit et recréé facilement, cela est probablement exagéré.

N'oubliez pas que la sécurité est construite en couches, afin de pouvoir obtenir un accès root, un compte doit avoir besoin de passer par un certain nombre de couches. Le verrouillage de l'accès, les clés privées SSH, les pare-feu, les restrictions d'heure de la journée [et le principe du moindre accès, c'est-à-dire ne donner accès qu'à ce qui est nécessaire, pas plus, la journalisation, les sauvegardes] devraient tous fonctionner ensemble dans le cadre d'une bonne sécurité.

Supplémentaire - Accès SUDO

Sudo est un mécanisme permettant à un utilisateur régulier d'exécuter certaines commandes avec un accès élevé, et est assez flexible et de portée variée. Bien qu'un aperçu de sudo ne soit pas approprié ici (mais est bien documenté si vous tapez man sudo dans la plupart des distributions, les étapes appropriées pourraient être -

1. Éditer /etc/sudoers - La plupart des variantes de Linux ont un programme spécial pour faire cela appelé "visudo" qui doit être exécuté en tant que root, et à peu près équivalent à utiliser l'éditeur système pour éditer /etc/sudoers (ce qui est une autre façon de faire ceci - bien que probablement frustré)

2. Ajoutez/modifiez les lignes appropriées pour permettre à un utilisateur donné de faire des choses particulières. Si, par exemple, vous vouliez qu'ils puissent monter des répertoires par exemple et sans avoir à entrer de mot de passe, vous entreriez une ligne comme :

   username    ALL=/sbin/mount NOPASSWD: ALL
   

Pour exécuter ensuite cette commande, l'utilisateur approprié exécuterait quelque chose comme

  sudo mount /dev/xxx /path/to/mount

Vous pouvez lister plusieurs lignes pour plusieurs commandes, utiliser des groupes plutôt que des utilisations - sudoers est un sous-système assez flexible. Dans de nombreuses distributions, il est également possible d'ajouter des fichiers avec des commandes dans un sous-répertoire comme /etc/sudoers.d

Ce qui suit est une réponse du post Unix Stackexchange
Comment exécuter à distance la commande ssh une commande sudo sans mot de passe.

Cette méthode permet à l'administrateur du serveur d'autoriser votre compte à exécuter une commande en tant que sudo sans spécifier le mot de passe. La commande est probablement l'appel à votre script, et elle n'est autorisée que lorsqu'elle est exécutée sous votre compte. Comme la commande autorisée est entièrement spécifiée, y compris les arguments, je pense que cette méthode est assez sécurisée.

vous pouvez dire à sudo d'ignorer le mot de passe pour certaines commandes.

par exemple. en /etc/sudoers

archemar  ALL = (www-data) NOPASSWD: /bin/rm -rf /var/www/log/upload.*

cela me permet d'utiliser

sudo -u www-data /bin/rm -rf /var/www/log/upload.*

comme archemar sans mot de passe.

Notez que

sudo -u www-data rm -rf /var/www/log/upload.*

ne fonctionnera pas (demandera un mot de passe) comme rm différent de /bin/rm .

Assurez-vous de modifier /etc/sudoers en utilisant visudo commande.

Une fois que vous aurez atteint le niveau avancé, vous souhaiterez peut-être avoir votre propre sudo fichiers en /etc/sudoers.d .