diff options
Diffstat (limited to 'content/Informatique/chroot.rst')
| -rw-r--r-- | content/Informatique/chroot.rst | 236 |
1 files changed, 0 insertions, 236 deletions
diff --git a/content/Informatique/chroot.rst b/content/Informatique/chroot.rst deleted file mode 100644 index d126d99..0000000 --- a/content/Informatique/chroot.rst +++ /dev/null @@ -1,236 +0,0 @@ -.. -*- mode: rst -*- -.. -*- coding: utf-8 -*- - -Mettre en place un environnement sftp chrooté -############################################# - -:date: 2010-04-08 -:tags: Libre, Hébergement, sftp - -*Note* : Je propose une autre approche pour mettre en place cette -solution : -`mettre-en-place-un-environnement-sftp-chroote-2/ <|filename|sftp.rst>`_ - -La demande -~~~~~~~~~~ - -Ma copine m'a demandé de trouver une solution simple pour échanger des -fichiers avec sa sœur, msn posant des problèmes… J'ai pensé à mon serveur ssh -et mettre en place une connexion sftp pour ça. Sur le principe cela a été -adopté avec une petite présentation de filezilla (je ne sais pas s'il existe -des clients sftp intégrés sous windows ?), j'ai donc commencé à mettre en place -le système. De mon côté, la condition principale est de n'autoriser les -connexions que par clef publique (pas de mot de passe), ma copine a tenu à ce -que sa sœur ne puisse pas accéder aux documents présents dans son home, et du -mien à ce que l'on ne puisse pas pour autant se promener dans l'arborescence du -serveur : il va donc falloir chrooter l'environnement. Il existe pas mal de -documentation la dessus sur internet, mais je me suis souvent retrouvé face à -des exemples incorrects ou incompatible avec le fait de passer par une clef -publique, je vais donc détailler les problèmes rencontrés. - -Le compte + clef publique -~~~~~~~~~~~~~~~~~~~~~~~~~ - -La première étape est de créer le compte, cela se fait assez simplement -: - -:: - - # adduser ${user} - -|Création de la clef ssh avec puttygen| et en répondant aux questions -par défaut… Vient ensuite la clef publique : filezilla gère les clefs -privés au format ppk (putty) et je n'ai pas trouvé d'outil pour les -générer sous windows. Je suis donc passé par wine + puttygen pour créer -la clef. Une fois celle-ci crée, on enregistre la partie publique et la -partie privée de la clef. La clef publique va être enregistrée dans le -fichier ${user}/.ssh/know\_host sur le serveur pour autoriser le client -à s'y connecter. La clef privée sera enregistrée de son côté au format -ppk pour être utilisée par filezilla (il est possible à partir de ce -fichier de générer une clef privée de type openssh). - -|image1| - -Il faut ensuite intégrer la clef privée dans filezilla en passant par -les paramètres : elle sera automatiquement lue à la connexion (il faut -choisir «interactive» dans le type d'authentification). (Attention : -sous windows j'ai rencontré des problèmes avec un répertoire contenant -des accents, la clef semblait être lue, mais la connexion ne se faisait -pas pour autant.) - -Chrooter l'environnement -~~~~~~~~~~~~~~~~~~~~~~~~ - -Aujourd'hui il est possible de chrooter nativement un environnement sftp -avec openssh. Il faut pour cela mettre en place une condition sur -l'utilisateur (ou le groupe) pour faire le chroot : - -:: - - Match user ${user} - ChrootDirectory /var/chroot/ - X11Forwarding no - AllowTcpForwarding no - ForceCommand internal-sftp - -Dans cet exemple le chemin /var/chroot sera utilisé comme racine lors -des connexions sftp. Ce répertoire doit être détenu par root:root et -avoir les droits 755. Cela veut dire que si notre utilisateur à pour -répertoire home /home/${user}, il se retrouvera dans -/var/chroot/home/${user} lors des connexions sftp. Il est nécessaire de -conserver le répertoire home de l'utilisateur pour que ssh accepte une -connexion par clef. En effet, lorsque l'utilisateur va se connecter, ssh -va lire dans son répertoire personnel pour lire le fichier -.ssh/know\_host et autoriser ou non la clef qui se présente. Ce qui -signifie que si l'on modifie le répertoire personnel, il faut aussi -déplacer cette arborescence (hors de question dans ce cas de mettre / -comme racine de l'utilisateur). À noter : j'ai préféré faire le match -sur le nom de l'utilisateur plutôt que sur son groupe (le groupe sera -utilisé par ailleurs). Dans le cas où nous avons plusieurs -utilisateurs, il est possible de les mettre à la suite (séparés par des -virgules). J'ai vu de nombreux tutoriaux qui indiquent comme répertoire -de chroot « /home/%u » (le répertoire de l'utilisateur standard), et -qui demandent de changer le répertoire de login de l'utilisateur par « / -». Je pense que c'est une très mauvaise idée : d'une part parce que cela -oblige à déposer les clefs à la racine du serveur, mais aussi à cause de -la contrainte d'openssh demandant à ce que le répertoire root soit -détenu par root : cela veut dire que l'utilisateur n'a pas le droit de -déposer de fichiers ou de créer de répertoires dans son propre home ! Le -plus simple est donc de prendre un autre répertoire pour l'échange, et -laisser le home de l'utilisateur pour la configuration. (Cela permet -aussi d'être sûr que le répertoire .ssh ne sera pas effacé par erreur -par l'utilisateur…) J'ai donc mis un lien symbolique pour lier le /home -de l'utilisateur avec son répertoire d'échange : - -.. code-block:: console - - # mkdir /home/${user}/echanges - # ln -s /var/chroot/home/${user} /home/${user}/echanges - -On retrouvera ainsi la possibilité de voir les fichiers déposés en -passant par le /home de l'utilisateur (même si ce dernier ne pourra pas -y aller…) - -Isoler l'environnement -~~~~~~~~~~~~~~~~~~~~~~ - -Maintenant que nous avons empêché l'utilisateur de se balader sur -l'ordinateur, nous allons l'empêcher de se balader dans les autres -répertoires des utilisateurs : cela se fait en une ligne de commande -(pour chacun des répertoires que nous allons ouvrir en sftp :) - -.. code-block:: console - - # for fichier in /var/chroot/home/* ; do chmod o-r ${fichier}; done - -Et voilà ! Les utilisateurs peuvent voir qu'il existe d'autres comptes -que le leur, mais ne peuvent pas y accéder. - -Autoriser le partage -~~~~~~~~~~~~~~~~~~~~ - -Maintenant que nous avons fermé les droits de manière générale il nous -reste à autoriser le partage des fichiers (après tout c'était le but de -la demande !) de manière plus fine. Cela implique pour moi deux choses : - -#. permettre à un autre utilisateur d'accéder aux données présentes -#. permettre à un autre utilisateur de déposer (ou de supprimer des - données) - -Pour le premier point, c'est facile il suffit d'ajouter l'utilisateur A -au groupe de l'utilisateur B : - -.. code-block:: console - - # usermod -a -G ${user} ${un_autre_utilisateur} - -Et l'utilsateur un\_autre\_utilisateur pourra donc accéder à l'ensemble -des fichiers pour les lire (et éventuellement les rapatrier chez lui). -Pour le second point (possibilité d'écrire et modifier) c'est un peu -plus compliqué; en gros nous voulons que les fichiers déposés par sftp -dans le répertoire de l'utilisateur ait comme groupe d'appartenance -celui du propriétaire du répertoire (quel que soit l'utilisateur qui -dépose) et qu'ils soient modifiable par le groupe (g+w) du -propriétaire. Par exemple : l'utilisateur A dépose un fichier dans le -répertoire d'échange de l'utilisateur B. Il faut que les droits de ce -fichier se présentent ainsi une fois le transfert terminé : - -.. code-block:: console - - $ ls -l fichier - -rw-rw---- 1 utilisateurA utilisateurB - -(ainsi l'un et l'autre pourront supprimer le fichier). Pour cela nous -allons utiliser une « bidouille » de l'os : le sgid bit. Derrière ce nom -barbare se trouve un marqueur qui permet de fixer le droit de tous les -fichiers qui seront créés dans le répertoire (plus d'info -`ici <http://en.wikipedia.org/wiki/Setuid>`_). Pour le déterminer on -passe par chmod : - -.. code-block:: console - - # chmod g+s /var/chroot/${user} - -|image2| - -Cela détermine bien quel est le groupe qui sera propriétaire du fichier, -mais cela ne donne pas à ce groupe le droit de le modifier pour autant ! -Sous linux, c'est la commande umask qui permet de déterminer les droits -des fichiers. Le problème est qu'il s'agit d'une commande liés à -l'environnement de l'utilisateur, et non pas aux répertoires sur -lesquels nous travaillons (à moins de passer par les ACLs mais cela est -déjà assez compliqué comme ça…). Ici, nous sommes dans un environnement -sftp, sans shell de login, donc sans possibilité d'exécuter la commande -directement, il faut que ce soit le serveur sftp qui le configure. J'ai -trouvé énormément de documentations (la plupart des bidouillages) pour -contourner le problème, mais la solution la plus simple vient de la -dernière version d'OpenSSH (5.4) sortie le 8 mars dernier. - - -Une nouvelle option sur le serveur sftp permet d'indiquer quel est -l'umask qui sera appliqué (dans notre cas 002) : dans le -fichier/etc/ssh/sshd\_config nous allons configurer les paramètres par -défaut du serveur sftp : Remplacer : - -:: - - Subsystem sftp /usr/lib/openssh/sftp-server.sh - -par : - -:: - - Subsystem sftp /usr/lib/openssh/sftp-server -u 002 - -Pour définir les droits umask qui seront appliqués par défaut pour -toutes les connexions sftp par défaut. Ce paramétrage est à redéfinir -pour les paramétrages personnalisés (bloc Match) : - -:: - - ForceCommand internal-sftp -u 002 - -Conclusion -~~~~~~~~~~ - -Nous avons un environnement bien hermétique, pouvant gérer -l'augmentation du nombre de compte (il suffit de refaire les chmod dans -notre environnement chrooté à la création du compte), et hermétique. Le -paramétrage côté serveur est effectivement assez lourd au début, mais je -pense que la mise à jour ne demande pas trop de travail, et on gère les -droits de manière assez fine (en passant par les groupes ce qui me -semble être dans la mentalité unix). Pour le client, il n'y a pas grand -chose à paramétrer (récupérer la clef et l'intégrer), et il n'y a -aucun risque que celui-ci vienne casser son paramétrage. On peut même -sauvegarder sa clef privée dans son home (le vrai), au cas où il -perdrait le fichier. - -.. |Création de la clef ssh avec puttygen| image:: |filename|../images/puttygen-300x276.jpg - :class: floatleft - - -.. |image1| image:: |filename|../images/filezilla-300x140.jpg - :class: floatright - -.. |image2| image:: |filename|../images/conf-300x175.jpg - :class: floatleft |