Si j’ai bien compris, de la session Apache (www-data) tu propose de me logger en tant que “serveur” pour récupérer la screen?
De plus ca fait mettre le mot de passe de la session serveur en clair dans un simple bash?
J’ai trouver une solution alternative.
Utiliser SSH2 avec php.
En utilisant des clé publiques/privées, le mot de passe ne sera pas en clair.
Le problème réside pour générer le fichier id_dsa.pub; car le nom d’utilisateur est www-data il me semble avec Apache2
Si je crée une session du nom de “www-data” pour créé le fichier “id_dsa.pub”; ensuite je copie la clé dans “authorized_keys” de la session “serveur”, que je veut piloter en ssh; normalement je pourrais bien me connecter en ssh en tant que “www-data” sur la session “serveur” avec ssh serveur@localhost
Je n’ai pas dit su, j’ai dit sudo ce qui n,'est pas pareil et ça marche très bien. Mais la solution avec les clefs ssh n’est pas mal sauf qu’il faut veiller à protéger la clef privée (accessible par apache donc potentiellement par un visiteur)
[ul][li]su permet de changer d’utilisateur[/li]
[li]sudo permet d’exécuter une commande (ou plusieurs) avec les droits d’un autre utilisateur[/li][/ul]
Oui tout était bon; sauf que screen à un bug avec les fichiers dans /dev/pts; il faut faire un Chmod pour que ça fonctionne.
De plus je lors de mes essais j’utilisai la session “site”, mais avec la session www-data plus de problèmes.
J’ai également autoriser directement mon script en .sh plutôt que l’application screen; mon script fait de toute façon appel à screen donc je suppose que c’est pareil au final.
Le problème est résolu et c’est bien moins complexe que ssh2 ^^
[quote=“ricardo”]Qu’appelles-tu “protéger” François ?
Un exemple stp !
J’avais suivi un tuto, de toi, il me semble, mais je ne le retrouve pas.[/quote]
Si il met les clefs ssh dans un répertoire accessible par apache, ces clefs pourront être chargées par un visiteur…