Le 10 janv. 2013 à 19:48, JC PAROLA <cont...@sels-ingenierie.com> a écrit :
> Le Thu, 10 Jan 2013 19:38:45 +0100, > Guillaume Pancak <gp...@imelbox.com> a écrit : > >> ssh_config et une config de sudo >> >> ~/.ssh/config >> >> avec un truc du genre >> >> command="sudo >> poste-client-",no-port-forwarding,no-X11-forwarding,no-agent-forwarding >> ssh-rsa La cLé SSH super longue client@poste-client" > > Mais sur un serveur dédié avec plusieurs dizaines d'hébergement, à > moins de mettre la même clé publique pour tous les hébergements (pas > top !) ça va être galère > De la même manière que la majorité des gens je suggérerais un chroot ssh (à l'intérieur desquels tu bindes les dossiers nécessaires à la bonne exécution de leurs applis (/usr, /bin, /sbin, ...). Côté www, il y a l'option suPHP, mais il y a également l'option ACL étendues, qui te permettent de définir des droits supplémentaires par rapport aux droits unix classiques. Sur mon ancien setup les fichiers étaient ownés par les utilisateurs mais une ACL étendu donnait le droit à l'utilisateur www-data de créer/modifier/supprimer les fichiers. Enfin, pour l'isolation de tes utilisateurs, le chroot est pas mal mais le container LXC est encore mieux. En plus du chroot, tu peux exécuter le shell de l'utilisateur dans des namespace réseau, PID, ... différents, et dropper les capabilities qui ne te plaisent pas (histoire d'éviter qu'une élévation de privilège permette à un de tes utilisateurs de rebooter le serveur). Cordialement Emmanuel Thierry _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
