Executé un script Shell en root
El_Diablo666
Messages postés
294
Date d'inscription
Statut
Membre
Dernière intervention
-
El_Diablo666 Messages postés 294 Date d'inscription Statut Membre Dernière intervention -
El_Diablo666 Messages postés 294 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
Je réalise une interface pour pouvoir lancer des script distant sur mon serveur dédié qui tourne sous Debian 5.0.
Une interface Web sur serveur A avec formulaire qui à la validation se connecte en SSH sur un serveur B exécute un script en lui passant des paramétrés.
Le tous fonctionne parfaitement (Authentification, passage des paramètres, lancement du script).
le problème c'est qu'il existe dans ce script des commandes qui ne peuvent se faire qu'on mode "root" comme la création de fichiers dans des répertoires avec "root" comme Owner et pas la possibilité de les changés.
Ma question donc: comment lancer le script a chaque appel en "root"?
Merci pour toutes info utiles.
Je réalise une interface pour pouvoir lancer des script distant sur mon serveur dédié qui tourne sous Debian 5.0.
Une interface Web sur serveur A avec formulaire qui à la validation se connecte en SSH sur un serveur B exécute un script en lui passant des paramétrés.
Le tous fonctionne parfaitement (Authentification, passage des paramètres, lancement du script).
le problème c'est qu'il existe dans ce script des commandes qui ne peuvent se faire qu'on mode "root" comme la création de fichiers dans des répertoires avec "root" comme Owner et pas la possibilité de les changés.
Ma question donc: comment lancer le script a chaque appel en "root"?
Merci pour toutes info utiles.
A voir également:
- Executé un script Shell en root
- Classic shell - Télécharger - Personnalisation
- Script vidéo youtube - Guide
- Kingo root - Télécharger - Divers Utilitaires
- Ghost script - Télécharger - Polices de caractères
- Mas script - Accueil - Windows
3 réponses
Je ne lancerais pas le scripte en root, mais éventuellement accordé sur le serveur où il a besoin les droits de faire un sudo (ou la commande qu'il a à faire) sans mot de passe avec.
Pour ça il faut configurer en tapant visudo
un exemple :
Si je ne me trompe pas, autorise l'utilisateur www-data à lancé la commande ssh depuis la machine hellraiser en tant que l'user read.
1) visudo
www-data hellraiser=(read) NOPASSWD:/usr/bin/ssh
Par contre je ne sais pas si c'est la meilleurs solution, il en existe sûrement d'autres.
Ivy
Pour ça il faut configurer en tapant visudo
un exemple :
Si je ne me trompe pas, autorise l'utilisateur www-data à lancé la commande ssh depuis la machine hellraiser en tant que l'user read.
1) visudo
www-data hellraiser=(read) NOPASSWD:/usr/bin/ssh
Par contre je ne sais pas si c'est la meilleurs solution, il en existe sûrement d'autres.
Ivy
La solution d'IvyAlice me paraît bien, car comme le montre la syntaxe qu'elle te propose tu peux faire en sorte qu'un sudoers n'ait pas systématiquement des droits root pour toutes les commandes, ce qui limite les éventuels risques d'une telle approche. Il faut juste installer le paquet sudo au préalable et le configurer avec la commande :
Tu as également des modules comme suphp avec apache qui pourraient répondre à ton besoin, comme celui-ci si tu utilises apache :
Mais dans ton cas précis je pense que l'approche la plus sûre dans ce cas de figure c'est plutôt de privilégier une solution basée purement sur ssh...
En tout cas, permettre l'upload de scripts qui peuvent contenir a priori lancés avec des droits root, ça me paraît risqué à première vue. Notamment si le site n'est pas en https, qu'on sniffe ton mot de passe et qu'on commence à faire n'importe quoi avec ton interface. Et je ne parle pas des attaques basées sur des injections, ou des fausses manipulations...
Qu'est ce que tu cherches à faire plus précisément ?
Bonne chance
visudo -s
Tu as également des modules comme suphp avec apache qui pourraient répondre à ton besoin, comme celui-ci si tu utilises apache :
libapache2-mod-suphp - Apache2 module to run php scripts with the owner permissions
Mais dans ton cas précis je pense que l'approche la plus sûre dans ce cas de figure c'est plutôt de privilégier une solution basée purement sur ssh...
En tout cas, permettre l'upload de scripts qui peuvent contenir a priori lancés avec des droits root, ça me paraît risqué à première vue. Notamment si le site n'est pas en https, qu'on sniffe ton mot de passe et qu'on commence à faire n'importe quoi avec ton interface. Et je ne parle pas des attaques basées sur des injections, ou des fausses manipulations...
Qu'est ce que tu cherches à faire plus précisément ?
Bonne chance
Merci pour votre réponse, je suis en train de faire une sorte de Cpanel pour la gestion de mes sites web sur un serveur dédié sans passer par la console SSH et en plus j'aimerais déléguer la tâche de création des sites web directement à mon équipe commerciale, donc ma création se fait sans passer par moi que je représente l'équipe technique. Pour vous mettre un peu dans le bain :
- Le serveur dédié est accessible via SSH depuis nos locaux avec une restriction par IP (la notre) sur cette accès chez l'hébergeur du serveur.
- Le serveur hébergeant l'interface faite en PHP est hébergé dans mes locaux et il n'est pas visible via Internet.
- Le serveur de l'application PHP lance les scripts via SSH sur le serveur dédié.
Je pense que de cette façon je n'aurai pas à avoir peur d'attaque de l'extérieur.
Si vous avez d'autres solutions à me proposer, car je souhaiterais élargir cette solution un jour et la rendre accessible en ligne pour mes clients par exemple.
- Le serveur dédié est accessible via SSH depuis nos locaux avec une restriction par IP (la notre) sur cette accès chez l'hébergeur du serveur.
- Le serveur hébergeant l'interface faite en PHP est hébergé dans mes locaux et il n'est pas visible via Internet.
- Le serveur de l'application PHP lance les scripts via SSH sur le serveur dédié.
Je pense que de cette façon je n'aurai pas à avoir peur d'attaque de l'extérieur.
Si vous avez d'autres solutions à me proposer, car je souhaiterais élargir cette solution un jour et la rendre accessible en ligne pour mes clients par exemple.