Lier monter un utilisateur SFTP après avoir utilisé chroot

Cet article est destiné aux administrateurs ou développeurs.

Le montage par liaison d'un utilisateur SFTP (Secure File Transfer Protocol) sur lequel l'opération chroot a été effectuée sur vos serveurs Red Hat® Enterprise Linux® (RHEL®) et CentOS® 6 (OpenSSH est 4.9p1 ou version ultérieure) crée les conditions suivantes :

L'utilisateur ne peut utiliser que SFTP et ne dispose pas d'un accès complet au shell via Secure Shell (SSH).
L'utilisateur est emprisonné dans son répertoire personnel et n'a aucun moyen d'en sortir.
Du point de vue de l'utilisateur, son répertoire personnel se trouve sur le serveur.
Ce montage lié est souvent nécessaire pour un développeur qui peut avoir besoin d'un accès en écriture à une ou plusieurs racines de document Apache® ou à un autre répertoire dans le but de télécharger ou de modifier du contenu Web.

Cet article décrit comment utiliser l'opération chroot pour définir le répertoire personnel de l'utilisateur et créer un montage lié dans ce répertoire personnel pour tous les répertoires externes (racine du document) auxquels il a besoin d'accéder. Un montage lié est le seul moyen de donner à l'utilisateur un accès aux données en dehors de son répertoire chroot. Vous n'êtes pas en mesure d'utiliser un lien symbolique (symlink) vers des données en dehors du chrootdirectory (par exemple, ln -s /home/user/http /var/www/http ). Après l'opération chroot, le système de fichiers n'a connaissance d'aucune donnée en dehors du répertoire chroot. Ce manque de connaissances rompt le lien symbolique. Comme alternative, vous pouvez déplacer le répertoire racine du document vers le répertoire personnel de l'utilisateur, puis le lier symboliquement à l'emplacement d'origine (par exemple, ln -s /var/www/html /home/user1/html ).

Le démon SSH (SSHD) propose des variables dynamiques dans la configuration pour l'opération chroot :

%u :nom d'utilisateur de l'utilisateur qui se connecte
%h :$HOME de l'utilisateur qui se connecte

SSHD est très strict sur la façon dont vous devez définir les autorisations. L'une de ces restrictions est que l'utilisateur ne peut pas écrire au niveau supérieur du répertoire chroot. Vous devez choisir un niveau supérieur approprié pour le répertoire chroot, tel que les paramètres suivants :

Définissez ChrootDirectory sur %h :L'utilisateur ne peut pas écrire dans son chemin d'accueil. Ils ont besoin soit d'un sous-dossier dans lequel ils peuvent écrire (par exemple les téléchargements), soit d'un montage lié à un autre emplacement dans lequel ils peuvent écrire (par exemple /var/www/html ).
Définissez ChrootDirectory sur /home/chroot :L'utilisateur peut écrire dans son chemin d'accès personnel, mais le niveau supérieur du répertoire chroot est protégé par les autorisations du système de fichiers, pas la prison chroot.

La première option utilise le répertoire chroot pour garantir la sécurité au lieu de s'appuyer sur les autorisations du système de fichiers. La deuxième option permet d'écrire dans le répertoire personnel mais signifie que le répertoire chroot est partagé avec d'autres utilisateurs, et seules les autorisations du système de fichiers arrêtent la divulgation d'informations. La bonne option dépend de vos besoins.

Lier le montage d'un utilisateur SFTP après une opération chrootée

Utilisez les étapes suivantes pour lier le montage à l'utilisateur :

Créez un groupe auquel vous assignerez tout utilisateur devant être emprisonné dans son répertoire personnel :
```
# groupadd sftponly
```

Créez l'utilisateur. Définissez le shell sur /bin/false et affectez l'utilisateur au groupe que vous avez créé ci-dessus :

# mkdir -p /home/chroot/$NEWUSER
# useradd -d /$NEWUSER -s /bin/false -G sftponly $NEWUSER    # Note: homedir is relative to the chroot
# pass}wd $NEWUSER

Mettez à jour le /etc/ssh/sshd_config fichier :

Commentez la ligne suivante :

 Subsystem       sftp    /usr/libexec/openssh/sftp-server

Ajoutez les lignes suivantes à la fin du fichier :

 Subsystem     sftp   internal-sftp
 Match Group sftponly
 ChrootDirectory /home/chroot   # OR     ChrootDirectory %h
 X11Forwarding no
 AllowTCPForwarding no
 ForceCommand internal-sftp

Testez la configuration, puis rechargez le SSHD :
```
 # sshd -t
 # service sshd reload
```

Configurer le répertoire personnel de l'utilisateur après l'opération chroot

Si le ChrootDirectory est /home/chroot , exécutez les commandes suivantes :

 # chmod 711 /home/chroot            # This prevents chrooted users from seeing other chrooted users' homedirs
 # chmod 755 /home/chroot/$NEWUSER
 # chown $NEWUSER:sftponly /home/chroot/$NEWUSER

Si le ChrootDirectory est %h , exécutez la commande suivante :
```
 # chown root:root /home/chroot/$NEWUSER
```

Créer des montages liés sur n'importe quel chemin en dehors du répertoire chroot auquel le l'utilisateur doit accéder

Ajoutez la ligne suivante au /etc/fstab fichier :

 /var/www/html   /home/chroot/$NEWUSER/www        none    bind    0 0`

Montez le répertoire :

 # mkdir /home/chroot/$NEWUSER/www
 # mount /home/chroot/$NEWUSER/www

Autorisations de mise à jour

Mettez à jour les autorisations du système de fichiers sur les répertoires auxquels l'utilisateur accède. Tenez compte des autres utilisateurs qui disposent actuellement d'un accès en lecture/écriture pour vous assurer que vous ne supprimez pas par inadvertance leurs autorisations. Vous pouvez effectuer cette étape de différentes manières, telles que la modification de la propriété de l'utilisateur, la modification de la propriété ou des autorisations du groupe, ou l'ajout de listes de contrôle d'accès aux fichiers (FACL).

L'exemple suivant montre les commandes permettant d'ajouter des FACL :

     # setfacl -Rm u:$NEWUSER:rwX /home/chroot/$NEWUSER/www/
     # setfacl -Rm d:u:$NEWUSER:rwX /home/chroot/$NEWUSER/www/

Problèmes potentiels

Les problèmes suivants peuvent survenir.

Autorisations de répertoire

Les autorisations de répertoire peuvent entraîner les problèmes suivants :

La fonction chroot intégrée de SFTP est très stricte en ce qui concerne les autorisations. Si les autorisations ne sont pas suffisamment sécurisées, vous recevez l'erreur suivante lorsque vous essayez de vous connecter :
```
    root@ftp01[ ~ ]# sftp $NEWUSER@localhost
    Connecting to localhost...
    chroottest@localhost's password:
    Write failed: Broken pipe
    Couldn't read packet: Connection reset by peer
```

Vous pouvez peut-être vous connecter, mais vous ne pouvez pas télécharger de fichiers. Dans ce cas, vous recevez l'erreur suivante :

    sftp> put test
    Uploading test to /$NEWUSER/test
    Couldn't get handle: Permission denied
    In both cases the problem is directory permissions.  Here's what a known-good directory structure looks like:
    root@ftp01[ ~ ]# ls -ld / /home /home/chroot /home/chroot/$NEWUSERdrwxr-xr-x. 28 root     root     4096 Aug 22 10:31 /
    drwxr-xr-x. 18 root     root     4096 Oct 10 10:49 /home
    drwx--x--x   3 root     root     4096 Oct 10 10:49 /home/chroot
    drwxr-xr-x   3 $NEWUSER $NEWUSER 4096 Oct 10 11:40 /home/chroot/$NEWUSER
    root@ftp01[ ~ ]#

SCP ne fonctionne pas

Ce type d'utilisateur fonctionne uniquement avec SFTP et ne fonctionne pas avec d'autres protocoles (par exemple, Remote Shell (RSH), Secure Contain Protect (SCP) ou File Transfer Protocol (FTP)).