Le 11/01/2013 10:52, JC PAROLA a écrit :
Je pense que ce point soulever par Emmanuel Thierry est beaucoup plus utilisé que ce que l'on pense. On m'a souvent demandé d'intervenir sur des serveurs mutualisés d'autres hébergeurs qui n'ont pas peur de fournir un accès SSH pour chaque utilisateur et pour les milliers de serveurs mutualisés qu'ils possèdent.
En accédant en ssh sur ces serveurs, je m'était rendu compte que ce n'était pas un nouveau shell mais bien du super chroot comme énoncé précédemment
Je vais creuser aussi la dessus.
un grand merci également Jonathan SCHNEIDER pour son coup de pouce pour le contact avec le développeur de lshell. Sincèrement, je suis persuader que le pb venait de mon install (apt sur Debian et port sur Freebsd). La mise en prod mettra tout cela en lumière.
Pour une telle utilisation il est recommandé en terme de sécurité et souplesse pour l'utilisateur (si l'on veux qu'il ait un environnement semi ouvert) de mettre en place des conteneurs (LXC ou VServer ou OpenVZ) plutôt que du chroot même avancé (sans forcément donner l'accès root à l'utilisateur), mais évidemment si vous voulez garder une seule IP publique frontale vous devrez avoir un proxy frontal et du nat pour les accès SSH (chaque conteneur ayant son propre SSHD, si possible lancé sur demande car seule une petite partie des utilisateurs utilisent du SSH). Cette solution est bien évidemment plus lourde à mettre en place et peut être contraignante et consommera plus de ressources par compte.
Si la solution d'un chroot était choisie, il vaut mieux avoir un kernel avec le patchset grsecurity qui permet entre autre aux utilisateurs non root de ne pas pouvoir voir les processus des autres utilisateurs (pratique si une commande comprenant un login ou mot de passe est lancé par un user) et différents renforcements de la sécurité des environnements chrootés.
cPanel par exemple permet d'autoriser une connexion chrootée pour les comptes clients, vous pouvez aussi regarder ce qui est fait de ce coté.