Outils pour utilisateurs

Outils du site


sftp_chroot

SFTP chroot

Objectif et problèmes

On veut sécuriser les connexion ftp d'une utilisatrice et l'on veut que cette utilisatrice ne puisse accéder qu'au répertoire de travail ftp qu'on lui affecte. Pour ce faire, on dispose de deux techniques : ftps et sftp.

ftps qui s'appuie sur tls et un serveur ftp. En configurant le serveur ftp, on peut facilement restreindre l'accès de toute utilisatrice à son répertoire de base. Il n'est pas nécessaire de lui donner accès à un shell (simple utilisatrice reconnue par le serveur ftp). Mais on peut ne pas vouloir ou ne pas pouvoir utiliser de certificats1) ! Dans ce cas, l'option ftps doit être écartée.

L'autre solution consiste à utiliser le protocole sftp. Un serveur sftp peut être réalisé de deux manières. La méthode “classique” s'appuie sur une application serveur SSH qui fournit un canal sécurisé à travers lequel le client dialogue avec une application serveur sftp. La deuxième technique2) - que nous développons ici - n'utilise pas de serveur ftp séparé, le service sftp étant intégralement fourni par l'application OpenSSH. Il en découle une contrainte et un problème. La contrainte est que le l'utilisatrice doit disposer d'un shell. Dans les deux cas, l'utilisatrice commence par emprunter un canal ssh. Une utilisatrice pouvant lancer un shell a automatiquement le droit de se promener dans tout le système de fichiers3).

On voudrait avoir les avantages de ftps (limitation à un répertoire de base) et ceux de sftp (pas de serveur ftp et par de certificats) ; autrement dit, emprisonner (jail) l'utilisatrice sftp dans un répertoire de base (typiquement, son répertoire “home”).

Les commandes et configurations présentées ci-après ont été validées sur un serveur Debian Squeeze. L'application à d'autres systèmes, distributions ou versions peut demander des adaptations (par ex. le comportement sftp par défaut d'OpenSSH).

Utilisatrice sftp limitée à sa home

Sources :

On peut très rapidement mettre en œuvre une configuration technique permettant d'atteindre cet objectif.

Adapter la configuration d'OpenSSH

# nano /etc/ssh/sshd_config

à la fin du fichier, ajouter le bloc suivant :

Match group jailed
    ChrootDirectory %h
    AllowTcpForwarding no
    ForceCommand internal-sftp

sauvergarder les modifications. On a indiqué que toute utilisatrice rattachée au groupe que l'on a décidé de nommer jailed sera restreinte à sa “home”. Rien ne change pour les autres. Ne pas oublier de demander à OpenSSH de recharger sa configuration afin que les modifications apportées soient prises en compte :

# /etc/init.d/ssh reload

Restreindre les droits des utilisatrices choisies

On suppose que les utilisatrices concernée existent déjà. Sinon, les créer suivant votre procédure habituelle. Dans l'exemple, on suppose que l'utilisatrice a été créée suivant les règles standard : son répertoire “home” est un sous répertoire direct du répertoire /home et le nom de sa “home” est identique à son login.

On commence par créer le groupe auquel appartiendront toutes les utilisatrices d'OnpenSSH dont nous souhaitons limiter les possibilités de navigation ;

# addgroup jailed

On ajoute l'utilisatrice (ici, flo) au groupe jailed et on modifie les droit sur sa “home” :

# usermod -G jailed flo
# chown root:root /home/flo
# chmod 755 /home/flo

À ce stade, flo ne peux plus que circuler dans sa home et en voir le contenu. Elle ne peut rien créer ni modifier. Il faut y remédier.

On crée des sous-répertoires de sa “home” et on lui donne tous les droits sur ces sous-répertoires. Par exemple :

# cd /home/flo
# mkdir data public_html
# chown flo:jailed data public_html
La “home” de flo peut contenir des fichiers de configuration créés automatiquement par le script ou la commande de création de comptes. Un 'ls -al' vous les montrera. Les supprimer !

Enfin, notre utilisatrice n'ayant besoin d'ouvrir de sessions interactive, inutile de lui affecter un shell. Lui retirer ce shell si la commande/script de création d'utilisatrice lui en a affecté un. Ceci s'obtient en lui affectant le shell /bin/false.

Contraintes liées à OpenSSh

Dans l'exemple précédent nous avons supposé que la “home” se trouvait immédiatement dans '/home'. Nous avons également supposé que ce répertoire appartenait à root:root. C'est bien la configuration par défaut mais ce n'est pas toujours le cas.

Dans toute autre configuration, le chemin depuis la racine du système de fichier jusqu'à la “home” de l'utilisatrice doit vérifier deux conditions, imposées par certaines versions d'OpenSSH4) :

  • il doit appartenir à root
  • il doit être ouvert au parcours (“exécutable”) par toute utilisatrice5).

Se connecter

Si vous utilisez un client ftp correct (Konqueror, Filezilla…), vous ne rencontrerez pas de problème pour vous connecter en sftp. Si vous êtes scotchée avec un client ftp de m…, il se peut qu'ils ne parvienne pas à établir une connexion sftp.

Accès Web

Souvent, l'accès sftp “restreint” s'applique à l'administratrice d'un site web. On souhaite alors qu'elle puisse téléverser des fichiers à la racine de son site. C'est ce suggérait la création du répertoire public_html, dans la section précédente.

Précautions

Il faut alors prendre garde à ce que l'utilisatrice ne puisse pas, par le biais du serveur web (Apache ou autre) exécuter un script qui lui permettrait de contourner les limitations mises en place et, par là même, de circuler dans tout le système de fichier. On prendra donc le plus grand soin dans la configuration du vhost.

Cette solution n'est donc applicable qu'aux site web se contentant de servir des fichiers statiques.

Racine dans le compte de l'utilisatrice

La technique la plus simple consiste à utiliser un répertoire standard, créé dans la “home” de l'utilisatrice (dans notre exemple public_html), comme racine du site web (DocumentRoot). Le vhost sera configuré en conséquence. Cette opération (classique) n'est pas détaillée ici.

Racine dans l'espace web

Si l'on souhaite que la racine du site web se trouve dans une arborescence web commune à toutes les utilisatrices (par ex. /var/www/flo), on est face à un contradiction. Cet espace (/var/www) se trouvant en dehors de la “home” de notre utilisatrice chrootée, le système ne nous laissera pas créer un lien (au sens trivial : link) que l'utilisatrice pourra exploiter6). Heureusement !

Qu'à cela ne tienne, on obtient le résultat fonctionnel souhaité en montant la racine du site web sur un répertoire accessible à l'utilisatrice. Pour ce faire, on utilise la technique de bind mount qui permet de monter une partie d'un système de fichier déjà monté, sans créer de conflit. Par exemple :

# mount /var/www/flo /home/flo/public_html -o bind

On prendra garde à ce que les droits du répertoire que l'on monte permette à la fois :

  • à l'utilisatrice (flo) d'écrire dans ce répertoire,
  • à l'utilisatrice sous l'identité de laquelle tourne le serveur web de lire dans ce répertoire.

Un des moyens d'atteindre cet objectif est de rendre l'utilisatrice sftp propriétaire de la racine du site tout en l'affectant au groupe sous l'identité duquel le serveur web est lancé (dans un cas standard, www-data).

Lire aussi : DefaultRoot, Symlinks and chroot()(en). Une discussion instructive sur les liens en environnement chrooté.

Virtualmin

Utilisatrices sftp chrootées

Si l'on utilise Virtualmin, il n'est pas judicieux de dériver les utilisatrices sftp chrootées à partir d'utilisatrice crées par Virtualmin. La contrainte d'appartenance à root:root de la “home” de l'utilisatrice est contradictoire avec la gestion qui en est faite par Virtualmin.

On créera donc des utilisatrices à partir des commandes de base, comme nous l'avons fait précédemment. Si l'on tient absolument à une interface graphique, rien n'empêche d'utiliser Webmin.

Déclaration du vhost et de la racine du site

Virtual server

Rien ne s'oppose à ce qu'on utilise un vhost créé à travers Virtualmin (virtual server). Dans ce cas, il faudra ajuster les droits du répertoire public_html du virtual server. Par exemple en supposant que le virtual server appartient à flo-www, en incluant le bind mount :

# mount /home/flo/public_html /home/flo-www/public_html -o bind
# chown flo /home/flo-www/public_html

Ainsi :

  • en tant propriétaire, flo pourra écrire dans le répertoire,
  • en tant que groupe, flo-www pourra lire (ou plus) le contenu du répertoire pour le servir via Apache.
On prendra garde à ce que le virtual server soit configuré convenablement afin d'éviter le contournement des limitations posées via le chroot d'OpenSSH : scripts, cgi, ssi, etc.

Si le besoin de coupler un compte sftp chrooté à un site web est fréquent, il sera intéressant de créer un modèle de serveur Virtualmin (server template).

Vhost standard

On peut se passer complètement de Virtualmin et créer le vhost “à la main” (en ligne de commande et éditeur ou à travers Webmin).

L'avantage est que l'on configure le vhost exactement comme on le souhaite, en ajoutant à partir de rien plutôt qu'en retirant à partir d'un profil Virtualmin trop permissif.

L'inconvénient est que l'on perd l'enrichissement qu'apporte la notion de virtual server (intégration, fonctionnalités) par rapport à la notion de virtual host (vhot). web perd l'intégration et les fonctionnalités mise à disposition par Virtualmin.

Authentification par clés

Tant qu'à proposer un accès sécurisé, autant le faire dans les meilleurs conditions. Au lieu d'utiliser une authentification rustique à l'aide d'un login et d'un mot de passe, mieux vaut utiliser l'authentification par clés, puisque ssh le permet. Du côté de l'utilisatrice, cela lui évite d'avoir à taper un login et un mot de passe. Du côté du serveur, on peut interdire toute autre forme d'authentification et n'autoriser la connexion que depuis certaines adresses IP.

Dans l'exemple traité précédemment, notre utilisatrice (flo) a été créée en suivant les règles habituelles. La déclaration des clés utilisables pour se connecter se fait donc suivant les règles habituelles. Il faudra cependant tenir compte du fait qu'elle ne possède plus son répertoire “home” puisqu'on l'a “donné” à root :

# cd /home/flo
# mkdir .ssh
# cd .ssh
# nano authorized_keys
puis copier/coller les clés publiques voulues, éventuellement restreintes aux IP voulues…

Si tel est bien le but poursuivi, ne pas oublier de désactiver la connexion par login/mdp, dans la configuration d'OpenSSH.

Alternatives

La technique alternative la plus documentée est celle qui passe par une mise en œuvre manuelle de comptes chrooted.

Elle est beaucoup plus lourde à mettre en place et ne peut être appliquée à des utilisatrices déjà créées. En effet, cette technique exige un processus particulier de création des comptes utilisatrices.

Pour une présentation complète de la solution :

1)
Imposés par le protocole TLS/SSL.
2)
Attention, cette technique n'est utilisable que pour les connexion utilisant la version 2 du protocole SSH.
3)
Elle sera limitée par les droits définis sur les fichier mais c'est une piètre consolation. Sans pouvoir les modifier, elle pourra consulter énormément de fichiers de configuration. La moindre erreur de configuration de ces fichier ou des droits sur les répertoires peut être directement exploitée.
4)
Et vérifiée à l'exécution.
5)
Même si cette possibilité est inhibée par d'autres mécanismes, dont celui que nous mettons en place.
6)
Évidemment, Root peut créer le lien, mais flo ne pourra pas le suivre, même si root la désigne comme propriétaire (owner).
sftp_chroot.txt · Dernière modification : 2014/05/17 01:01 de 127.0.0.1