Bonjour, Je suis confronté au cahier des charges suivant pour lequel j'ai du mal a répondre et pourtout tous les monde à du y être confronté - donner un accès ssh à des utilisateurs virtuels (cas des hébergement tournant en mode PHP où tout appartient à apache: pas de user systeme) - confiner les users virtuels dans un $HOME - ne pas avoir à copier toutes les librairies dynamiques dans $HOME pour un chroot 'pure' - pouvoir utiliser des binaires en dehors du chroot (exemple mysqladmin) concernant le choot ssh, la doc Debian résume bien le sujet (http://www.debian.org/doc/manuals/securing-debian-howto/ap-chroot-ssh-env.fr...). Cela me parait old school. J'ai également testé tout un tas de shell dont le plus proche serait lshell mais si je n'ai pas de user systeme, j'ai le même $HOME (celui d'apache) Je cherche actuellement du côté de PAM Mysql ou PAM LDAP, je pense qu'avec des utilisateurs virtuels je n'ai guère le choix. qu'en pensez-vous ?
Le jeudi 19 décembre 2013 11:36:00 JC PAROLA a écrit :
Bonjour,
Je suis confronté au cahier des charges suivant pour lequel j'ai du mal a répondre et pourtout tous les monde à du y être confronté
Bonjour JC : En ce qui me concerne : obligation de conseil : remettre en cause le cahier des charges du client et requalifier le besoin des comptes shell, situation & co :) amicalement, -- .°. Christophe Casalegno | CTO / Chief Technical Officer Digital Network | Security, Hosting & managed services http://www.digital-network.net | http://bit.ly/14MKprj Phone : +33.618.952.154 | Fax : +33.177.758.868
Tip N°1 : utiliser php en fcgi avec SuExec apache ou en FPM. cela te permettra déjà d'avoir 1 user / site, et de mieux cloisonner. Tip N°2 : utilise MySecureShell pour faire des environnements en jail Tip N°3 : utilise lshell pour limiter les commandes disponibles a tes utilisateurs Question : pourquoi filer un accès SSH à des users sur un environnement mut ? effectivement le cahier des charges est a redéfinir... Le 19/12/2013 12:06, Christophe Casalegno a écrit :
Le jeudi 19 décembre 2013 11:36:00 JC PAROLA a écrit :
Bonjour,
Je suis confronté au cahier des charges suivant pour lequel j'ai du mal a répondre et pourtout tous les monde à du y être confronté Bonjour JC : En ce qui me concerne : obligation de conseil : remettre en cause le cahier des charges du client et requalifier le besoin des comptes shell, situation & co :)
amicalement,
Bonjour, Le 19 déc. 2013 à 13:10, Pierre `Sn4kY` DOLIDON a écrit :
Tip N°1 : utiliser php en fcgi avec SuExec apache ou en FPM. cela te permettra déjà d'avoir 1 user / site, et de mieux cloisonner.
Je plussoie violemment pour php-fpm. Ajouter à ça une directive open_basedir par utilisateur pour les empêcher d'aller voir plus haut que leur $HOME
Tip N°2 : utilise MySecureShell pour faire des environnements en jail Tip N°3 : utilise lshell pour limiter les commandes disponibles a tes utilisateurs
Concernant le chroot du shell, même avec un OpenSSH standard, c'est inutile de copier les dossiers, il suffit de les monter en bind mount. Cordialement Emmanuel Thierry
Question : pourquoi filer un accès SSH à des users sur un environnement mut ? effectivement le cahier des charges est a redéfinir...
Le 19/12/2013 12:06, Christophe Casalegno a écrit :
Le jeudi 19 décembre 2013 11:36:00 JC PAROLA a écrit :
Bonjour,
Je suis confronté au cahier des charges suivant pour lequel j'ai du mal a répondre et pourtout tous les monde à du y être confronté Bonjour JC : En ce qui me concerne : obligation de conseil : remettre en cause le cahier des charges du client et requalifier le besoin des comptes shell, situation & co :)
amicalement,
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Merci pour ces éléments, effectivement le besoin client a changé, le client transforme son serveur dédié mono-site en multi-site.( merci Christophe :-) ) Pour le multi-site j'ai l'habitude d'utiliser suPHP en mode paranoïd, j'avais essayé fpm à ses débuts sans grand succès. User système mis à part (c.a.d sécurisation des hébergements web), concernant MySecureShell...c'est pour sftp et pas du shell en console Pour lshell effectivement, le shell choisit semble bon (dépendance python quand même). Dans mon cas, pam_mysql (pour avoir des users par hébergement) et lshell semble suffisant .... ou alors j'install suphp. Le 19/12/2013 13:24, Emmanuel Thierry a écrit :
Bonjour,
Le 19 déc. 2013 à 13:10, Pierre `Sn4kY` DOLIDON a écrit :
Tip N°1 : utiliser php en fcgi avec SuExec apache ou en FPM. cela te permettra déjà d'avoir 1 user / site, et de mieux cloisonner. Je plussoie violemment pour php-fpm. Ajouter à ça une directive open_basedir par utilisateur pour les empêcher d'aller voir plus haut que leur $HOME
Tip N°2 : utilise MySecureShell pour faire des environnements en jail Tip N°3 : utilise lshell pour limiter les commandes disponibles a tes utilisateurs Concernant le chroot du shell, même avec un OpenSSH standard, c'est inutile de copier les dossiers, il suffit de les monter en bind mount.
Cordialement Emmanuel Thierry
Question : pourquoi filer un accès SSH à des users sur un environnement mut ? effectivement le cahier des charges est a redéfinir...
Le 19/12/2013 12:06, Christophe Casalegno a écrit :
Le jeudi 19 décembre 2013 11:36:00 JC PAROLA a écrit :
Bonjour,
Je suis confronté au cahier des charges suivant pour lequel j'ai du mal a répondre et pourtout tous les monde à du y être confronté Bonjour JC : En ce qui me concerne : obligation de conseil : remettre en cause le cahier des charges du client et requalifier le besoin des comptes shell, situation & co :)
amicalement,
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Hello, Tu peux regarder du côté de mod_ruid2 pour apache, c'est cool dans un environnement ou tu as vraiment beaucoup de sites car la conf est pas très compliquée Le 19 décembre 2013 14:07, JC PAROLA <contact@sels-ingenierie.com> a écrit :
Bonjour,
Merci pour ces éléments, effectivement le besoin client a changé, le client transforme son serveur dédié mono-site en multi-site.( merci Christophe :-) )
Pour le multi-site j'ai l'habitude d'utiliser suPHP en mode paranoïd, j'avais essayé fpm à ses débuts sans grand succès.
User système mis à part (c.a.d sécurisation des hébergements web),
concernant MySecureShell...c'est pour sftp et pas du shell en console
Pour lshell effectivement, le shell choisit semble bon (dépendance python quand même).
Dans mon cas, pam_mysql (pour avoir des users par hébergement) et lshell semble suffisant ....
ou alors j'install suphp.
Le 19/12/2013 13:24, Emmanuel Thierry a écrit :
Bonjour,
Le 19 déc. 2013 à 13:10, Pierre `Sn4kY` DOLIDON a écrit :
Tip N°1 : utiliser php en fcgi avec SuExec apache ou en FPM. cela te
permettra déjà d'avoir 1 user / site, et de mieux cloisonner.
Je plussoie violemment pour php-fpm. Ajouter à ça une directive open_basedir par utilisateur pour les empêcher d'aller voir plus haut que leur $HOME
Tip N°2 : utilise MySecureShell pour faire des environnements en jail
Tip N°3 : utilise lshell pour limiter les commandes disponibles a tes utilisateurs
Concernant le chroot du shell, même avec un OpenSSH standard, c'est inutile de copier les dossiers, il suffit de les monter en bind mount.
Cordialement Emmanuel Thierry
Question : pourquoi filer un accès SSH à des users sur un environnement
mut ? effectivement le cahier des charges est a redéfinir...
Le 19/12/2013 12:06, Christophe Casalegno a écrit :
Le jeudi 19 décembre 2013 11:36:00 JC PAROLA a écrit :
Bonjour,
Je suis confronté au cahier des charges suivant pour lequel j'ai du mal a répondre et pourtout tous les monde à du y être confronté
Bonjour JC : En ce qui me concerne : obligation de conseil : remettre en cause le cahier des charges du client et requalifier le besoin des comptes shell, situation & co :)
amicalement,
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Nathan Delhaye 06 69 27 64 25 0805 696 494
Le 19/12/2013 14:07, JC PAROLA a écrit :
Bonjour,
Merci pour ces éléments, effectivement le besoin client a changé, le client transforme son serveur dédié mono-site en multi-site.( merci Christophe :-) )
Pour le multi-site j'ai l'habitude d'utiliser suPHP en mode paranoïd, j'avais essayé fpm à ses débuts sans grand succès.
User système mis à part (c.a.d sécurisation des hébergements web),
concernant MySecureShell...c'est pour sftp et pas du shell en console oui et non. avec une directive de ce type : Shell /usr/bin/lshell tu indique d'utiliser le shell lshell qui lui est un shell SSH.
Pour lshell effectivement, le shell choisit semble bon (dépendance python quand même).
Dans mon cas, pam_mysql (pour avoir des users par hébergement) et lshell semble suffisant ....
ou alors j'install suphp.
Le 19/12/2013 13:24, Emmanuel Thierry a écrit :
Bonjour,
Le 19 déc. 2013 à 13:10, Pierre `Sn4kY` DOLIDON a écrit :
Tip N°1 : utiliser php en fcgi avec SuExec apache ou en FPM. cela te permettra déjà d'avoir 1 user / site, et de mieux cloisonner. Je plussoie violemment pour php-fpm. Ajouter à ça une directive open_basedir par utilisateur pour les empêcher d'aller voir plus haut que leur $HOME
Tip N°2 : utilise MySecureShell pour faire des environnements en jail Tip N°3 : utilise lshell pour limiter les commandes disponibles a tes utilisateurs Concernant le chroot du shell, même avec un OpenSSH standard, c'est inutile de copier les dossiers, il suffit de les monter en bind mount.
Cordialement Emmanuel Thierry
Question : pourquoi filer un accès SSH à des users sur un environnement mut ? effectivement le cahier des charges est a redéfinir...
Le 19/12/2013 12:06, Christophe Casalegno a écrit :
Le jeudi 19 décembre 2013 11:36:00 JC PAROLA a écrit :
Bonjour,
Je suis confronté au cahier des charges suivant pour lequel j'ai du mal a répondre et pourtout tous les monde à du y être confronté Bonjour JC : En ce qui me concerne : obligation de conseil : remettre en cause le cahier des charges du client et requalifier le besoin des comptes shell, situation & co :)
amicalement,
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 19/12/2013 13:24, Emmanuel Thierry a écrit :
Bonjour,
Le 19 déc. 2013 à 13:10, Pierre `Sn4kY` DOLIDON a écrit :
Tip N°1 : utiliser php en fcgi avec SuExec apache ou en FPM. cela te permettra déjà d'avoir 1 user / site, et de mieux cloisonner. Je plussoie violemment pour php-fpm. Ajouter à ça une directive open_basedir par utilisateur pour les empêcher d'aller voir plus haut que leur $HOME
Tip N°2 : utilise MySecureShell pour faire des environnements en jail Tip N°3 : utilise lshell pour limiter les commandes disponibles a tes utilisateurs Concernant le chroot du shell, même avec un OpenSSH standard, c'est inutile de copier les dossiers, il suffit de les monter en bind mount.
C'est compliqué ! pourquoi ne pas utiliser "internal-sftp" plutôt que "sftp-server" en "Subsystem sftp" ? pas besoin de se faire chier a monter ou a copier les environnements dans la jail... ça impose d'autres contraintes, mais il me semble qu'on s'écarte, puisque le monsieur désire du SSH.
Cordialement Emmanuel Thierry
Question : pourquoi filer un accès SSH à des users sur un environnement mut ? effectivement le cahier des charges est a redéfinir...
Le 19/12/2013 12:06, Christophe Casalegno a écrit :
Le jeudi 19 décembre 2013 11:36:00 JC PAROLA a écrit :
Bonjour,
Je suis confronté au cahier des charges suivant pour lequel j'ai du mal a répondre et pourtout tous les monde à du y être confronté Bonjour JC : En ce qui me concerne : obligation de conseil : remettre en cause le cahier des charges du client et requalifier le besoin des comptes shell, situation & co :)
amicalement,
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 19 déc. 2013 à 14:33, Pierre `Sn4kY` DOLIDON a écrit :
Le 19/12/2013 13:24, Emmanuel Thierry a écrit :
Bonjour,
Le 19 déc. 2013 à 13:10, Pierre `Sn4kY` DOLIDON a écrit :
Tip N°1 : utiliser php en fcgi avec SuExec apache ou en FPM. cela te permettra déjà d'avoir 1 user / site, et de mieux cloisonner. Je plussoie violemment pour php-fpm. Ajouter à ça une directive open_basedir par utilisateur pour les empêcher d'aller voir plus haut que leur $HOME
Tip N°2 : utilise MySecureShell pour faire des environnements en jail Tip N°3 : utilise lshell pour limiter les commandes disponibles a tes utilisateurs Concernant le chroot du shell, même avec un OpenSSH standard, c'est inutile de copier les dossiers, il suffit de les monter en bind mount.
C'est compliqué ! pourquoi ne pas utiliser "internal-sftp" plutôt que "sftp-server" en "Subsystem sftp" ? pas besoin de se faire chier a monter ou a copier les environnements dans la jail... ça impose d'autres contraintes, mais il me semble qu'on s'écarte, puisque le monsieur désire du SSH.
Le bind mount j'en parlais pour du SSH, pas du SFTP. Cordialement Emmanuel Thierry
Le 19/12/2013 14:33, Pierre `Sn4kY` DOLIDON a écrit :
Le 19/12/2013 13:24, Emmanuel Thierry a écrit :
Bonjour,
Le 19 déc. 2013 à 13:10, Pierre `Sn4kY` DOLIDON a écrit :
Tip N°1 : utiliser php en fcgi avec SuExec apache ou en FPM. cela te permettra déjà d'avoir 1 user / site, et de mieux cloisonner. Je plussoie violemment pour php-fpm. Ajouter à ça une directive open_basedir par utilisateur pour les empêcher d'aller voir plus haut que leur $HOME
Tip N°2 : utilise MySecureShell pour faire des environnements en jail Tip N°3 : utilise lshell pour limiter les commandes disponibles a tes utilisateurs Concernant le chroot du shell, même avec un OpenSSH standard, c'est inutile de copier les dossiers, il suffit de les monter en bind mount.
C'est compliqué ! pourquoi ne pas utiliser "internal-sftp" plutôt que "sftp-server" en "Subsystem sftp" ? pas besoin de se faire chier a monter ou a copier les environnements dans la jail... ça impose d'autres contraintes, mais il me semble qu'on s'écarte, puisque le monsieur désire du SSH.
J'allais justement poser la question si c'était du SFTP ou SSH dont il y a besoin... Peut-être que le mieux serait de poser la question des besoins avant de parler de la solution... Quelles sont par ailleurs les contraintes, typiquement peux-tu installer n'importe quelle version d'Openssh ou non ? Suivant les versions on peut plus ou moins faire de choses... Cdlt, JYL
Le 19/12/2013 20:38, Jean-Yves LENHOF a écrit :
J'allais justement poser la question si c'était du SFTP ou SSH dont il y a besoin...
Peut-être que le mieux serait de poser la question des besoins avant de parler de la solution...
Quelles sont par ailleurs les contraintes, typiquement peux-tu installer n'importe quelle version d'Openssh ou non ? Suivant les versions on peut plus ou moins faire de choses...
Cdlt,
JYL
Je suis sur FreeBSD 9.1 et je peux donc installer *n'importe quelle version* d'Opensh. J'avais effectivement entendu parlé d'un patch d'Openssh permettrant un chroot "propre". en terme de contrainte, il faut que l'utilisateur ait accès aux commandes liée au filestystem (cp, mv ...), pouvoir utilisez également des binaires extrernes (tar, unzip, mysqldump). outre cet aspect, j'avais une "problématique" supplémentaire lié au fait que mon serveur wed tourne en mod_php et que par conséquent il n'y a pas de user spécifique par hébergement. De ce côté là, j'ai trouvé la solution en passant par du pam_mysql. Du coup je peux créer des users avec les même id que celui qui fait tourné apache. Et je retombe sur mes pattes comme ça (une autre solution existe avec l'option -u de useradd) Quelle version d'Openssh permettrait plus de choses ?
Le 20/12/2013 11:15, JC PAROLA a écrit :
Le 19/12/2013 20:38, Jean-Yves LENHOF a écrit :
J'allais justement poser la question si c'était du SFTP ou SSH dont il y a besoin...
Peut-être que le mieux serait de poser la question des besoins avant de parler de la solution...
Quelles sont par ailleurs les contraintes, typiquement peux-tu installer n'importe quelle version d'Openssh ou non ? Suivant les versions on peut plus ou moins faire de choses...
Cdlt,
JYL
Je suis sur FreeBSD 9.1 et je peux donc installer *n'importe quelle version* d'Opensh.
J'avais effectivement entendu parlé d'un patch d'Openssh permettrant un chroot "propre".
en terme de contrainte, il faut que l'utilisateur ait accès aux commandes liée au filestystem (cp, mv ...), pouvoir utilisez également des binaires extrernes (tar, unzip, mysqldump).
outre cet aspect, j'avais une "problématique" supplémentaire lié au fait que mon serveur wed tourne en mod_php et que par conséquent il n'y a pas de user spécifique par hébergement.
De ce côté là, j'ai trouvé la solution en passant par du pam_mysql. Du coup je peux créer des users avec les même id que celui qui fait tourné apache.
Et je retombe sur mes pattes comme ça (une autre solution existe avec l'option -u de useradd)
Quelle version d'Openssh permettrait plus de choses ?
'lo, Tu n'expliques toujours que le but de ce que tu voudrais mettre en place... Pas le problème initial (développement ? avec un framework ? à priori php... pourquoi avoir besoin de cp/mv/tar/zip/unzip, etc). Pourquoi le développeur a besoin d'un accès au serveur ? (de prod si je comprends bien) D'habitude les développeurs ont un petit apache/php en local, puis on intégre sur de la qualif avant de faire de la prod.... Bref... Pour ma part, je trouve que ça commence à faire beaucoup de commandes autorisées pour un simple chroot... soit As-tu regardé à utiliser le répertoire ~/public_html avec l'utilisation du module UserDir d'apache qui permet de ne pas avoir à mapper ton utilisateur unix avec le même uid qu'apache et que chacun travailles avec son propre utilisateur ? Concernant openssh, c'est juste que j'aime bien avoir les éléments... et si tu nous sortait une version 3.8 d'il y a 10 ans c'est plus chiant de faire qq chose de propre... Cdlt,
Le 20/12/2013 14:42, Jean-Yves LENHOF a écrit :
Tu n'expliques toujours que le but de ce que tu voudrais mettre en place... Pas le problème initial (développement ? avec un framework ? à priori php... pourquoi avoir besoin de cp/mv/tar/zip/unzip, etc). Pourquoi le développeur a besoin d'un accès au serveur ? (de prod si je comprends bien) D'habitude les développeurs ont un petit apache/php en local, puis on intégre sur de la qualif avant de faire de la prod....
en fait, il s'agit de symphony le framework php, et le dev a beoin de lancer des commandes propres à ce framework
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 20/12/2013 15:19, JC PAROLA a écrit :
Le 20/12/2013 14:42, Jean-Yves LENHOF a écrit :
Tu n'expliques toujours que le but de ce que tu voudrais mettre en place... Pas le problème initial (développement ? avec un framework ? à priori php... pourquoi avoir besoin de cp/mv/tar/zip/unzip, etc). Pourquoi le développeur a besoin d'un accès au serveur ? (de prod si je comprends bien) D'habitude les développeurs ont un petit apache/php en local, puis on intégre sur de la qualif avant de faire de la prod....
Salut, Chez L'Autre Net (hébergeur associatif), nous proposons bien du SSH dans un environnement chrooté à la homedir du membre adhérent. Le code utilisé est ici : https://dev.alternc.org/svn/alternc-ssh/trunk/alternc-lxc/ Via le panel AlternC, le membre démarre la machine LXC, puis il s'y connecte en SSH, fait sa tambouille et détruit la machine. http://aide.lautre.net/Se-connecter-en-SSH A bientôt, - -- Olivier Duquesne aka DaffyDuke http://www.coincoin.fr.eu.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iEYEARECAAYFAlK7Q2YACgkQRjQjk2P2DCxS1QCgxHOPikAvEwlFWy3c2KEinL5Q O1sAoKuVVmmXYKHfuxdeMwKUPvMAJh8W =rq36 -----END PGP SIGNATURE-----
participants (7)
-
Christophe Casalegno -
Emmanuel Thierry -
JC PAROLA -
Jean-Yves LENHOF -
Nathan delhaye -
Olivier Duquesne -
Pierre `Sn4kY` DOLIDON