Le 12 janv. 2013 à 02:48, Jean Weisbuch <j...@plusquenet.net> a écrit :

> 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.

Le point avec LXC est qu'il est possible de "virtualiser" à la carte. On peut 
"virtualiser" le filesystem, les PID, les devices, etc, mais garder le même net 
namespace. C'est précisément ce que je fais sur l'un de mes setup où j'ai gardé 
une stock réseau unique pour tous les conteneurs. Cela évite un NAT  inutile.
Concrètement cela pourrait se faire pour des restrictions utilisateur en ayant 
un seul process sshd, lequel pourrait créer à la volée un nouveau conteneur 
pour chaque session ssh ou utilisateur.

Cordialement.
Emmanuel Thierry
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

Répondre à