Troumad wrote: > Un camarade a trouvé la solution à mes questions (il me semble), je > vous passe l'adresse de la réponse s'il y a des gens intéressé. Mais > mon niveau d'anglais, comme mon niveau en LINUX, ne m'ont pas permis > de bien comprendre.
Comme la question m'intéresse aussi, j'ai lu et traduit l'article en question. Le voila ci-dessous. Si tu as testé proftp, comment faire pour que l'utilisateur à distance ne voit *que* un répertoire donné du host, et qu'il ne puisse pas remonter dans l'arborescence ? 9a se trouve dans proftpd.conf, mais où ? "Comment puis-je permettre à un utilisateur d'utiliser scp ou sftp, mais ne pas autoriser ssh (c.a.d. d'obtenir un shell ou d'exécuter d'autres programmes) ? La réponse est que c'est un peu compliqué à faire. scp1 et scp2 utilise ssh en sub process pour se connecter au host et exécute le serveur approprié pour converser avec scp et sftp-server respectivement. Donc, la meilleure chose à faire est de resteindre l'utilisateur à exécuter le serveur de transfert de fichier. La façon la plus simple de le faire est de créer un compte uniquement à cet effet, en lui donnant un shell qui ne lui permet de faire que du transfert de fichiers. SSH utilise toujours le shell pour exécuter des programmes à distance, aussi c'est une restriction fiable. SSH appelle le shell avec l'option -c pour exécuter le programme. La modification devrait accepter ou bien scp avec les arguments appropriés, ou sftp-server, suivant le cas. SSH2 est fourni avec ssh-dummy-shell pour la même tâche, ainsi il ne gère naturellement que sftp. Si vous ne voulez pas limiter le compte utilisateur de cette façon, cela devient plus difficile. Vous pouvez également essayer une identification à clé publique avec une commande forcée. C'est simple avec SSH2 : # SSH2 [remote:~/.ssh2/authorization] key users_key.pub command /usr/local/bin/sftp-server Avec SSH1, c'est plus compliqué, parce que le client passe des arguments à scp dans la commande à distance. Par exemple : client command runs this on server ---------------------------------------------- scp foo server:bar scp -t bar scp server:bar foo scp -f bar scp *.txt server:dir scp -d -t dir Ainsi, vous avez besoin d'un programme enveloppe pour le resteindre. Voila un exemple : # SSH1 [remote:~/.ssh/authorized_keys] command="/path/to/scp-wrapper" 1024 37 1440913682374... (voir le script Perl à http://www.snailbook.com/faq/scp-wrapper.txt) Mais chacune de ces solutions a un défaut : l'autorisation et les clès autorisées sont Writable par le compte utilisateur cible. Ces mesures sont aisément contournées en utilisant simplement scp pour modifier ces fichiers. Donc vous devez les protéger des modifications. Vous pouvez interdire l'écriture dans le répertoire de controle SSH du compte, ou vous pouvez changer son emplacement par ex. avec l'instruction ssh2 UserConfigDirectory. Par-delà ceci, cependant, il y a encore plus de trous. Par exemple, SSH exécute le shell de l'utilisateur pour exécuter la commande à distance, avec $SHELL -c "commande". Ainsi, vous pouvez tranquillement exécuter n'importe quelle commande avec scp, dans le fichier de démarrage du shell à distance (par ex ~/.bashrc), et elles seront exécutées la prochaine fois que vous lancez scp. Vous devez donc verrouiller le répertoire home distant de façon qu'il ne soit pas writable pour l'utilisateur, et créer un espace distinct pour y déposer les fichiers."
Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur "http://www.mandrakestore.com";
