SFTP, chroot et pas de SSH : bloquer un utilisateur dans un répertoire
Salut,
Un petit article sur ce sujet récurrent car il y a plein de méthodes, dont une assez simple, mais avec 2/3 points de paramétrage précis.
Le but est de permettre à un client/fournisseur d’envoyer/récupérer des fichiers sur un serveur, en SFTP, sans pour autant lui donner accès en SSH (exécuter des commandes) et sans voir autre part que son « home ».
Le tout sur un serveur SSH déjà monté et par ailleurs utilisé pour du SSH normal en interne, avec du SFTP normal aussi.
Il y a 3 méthodes courantes pour commencer à jouer avec les chroot ssh/sftp :
- Héberger un serveur SSH en chroot normal : c’est chiant. Créer un « home », reproduire un minimum d’arborescence standard, d’utilisateurs etc.
- Utiliser rssh comme shell alternatif, c’est un shell qui limite l’utilisateur à du SFTP, SCP, CVS, RSYNC etc. On choisit ce qu’on veut tolérer. Mais, l’utilisateur peut quand même se promener dans le système (tout « / »).
- Enfin, ce que je vais décrire : utiliser la fonctionnalité de « chroot » intégrée aux serveurs SSH (serveur ssh >= 4.8, donc n’importe quel SSH d’une Debian stable de nos jours). On va simplement brider quelques comptes et mettre quelques permissions bien senties.
Adaptation d’un utilisateur
Le mieux est de prévoir large : on risque d’avoir plusieurs clients/fournisseurs qui voudront accéder.
On va donc créer un groupe des utilisateurs SFTP seulement, nommé « sftpusers ».
Je crée un utilisateur pour mon client, nommé xfer1, en changeant son home :
xfer1:x:1011:1012:Transfert client1,,,:/transferts_partenaires/xfer1/:bin/bash
Notez que le groupe 1012 est le groupe « sftpusers » :
$ id xfer1 uid=1011(xfer1) gid=1012(sftpusers) groupes=1012(sftpusers)
Création du répertoire d’échange, permissions
On crée l’arborescence qui va servir de home bidon à tout ces utilisateurs :
$ mkdir --parents /transferts_partenaires/xfer1/ $ chown -R root:sftpusers /transferts_partenaires/ $ chmod -R 750 /transferts_partenaires/
Les permissions ci-dessus sont hyper importantes. Le serveur SFTP refusera la connexion si le home de ces utilisateurs n’est pas en écriture uniquement pour le root ! Donc oui, en l’état, notre utilisateur xfer1:sftpusers
ne peut pas écrire dans son home. Il pourra lire, ce qui peut être suffisant si vous lui mettez simplement des fichiers à disposition. Mais pour écrire, il faudra créer un sous-répertoire, genre « upload ».
mkdir /transferts_partenaires/xfer1/upload/ chown xfer1:sftpusers /transferts_partenaires/xfer1/upload/ chmod 700 /transferts_partenaires/xfer1/upload/
Déclaration du compte en SFTP uniquement
Enfin, on paramètre le serveur SSH comme suit. Modifiez votre fichier /etc/ssh/sshd_config
:
# param par défaut, on change : Subsystem sftp /usr/lib/openssh/sftp-server Subsystem sftp internal-sftp -f AUTH -l VERBOSE # plus loin... Match Group sftpusers ChrootDirectory /transferts_partenaires/%u ForceCommand internal-sftp AllowTcpForwarding no GatewayPorts no X11Forwarding no
A noter que les AllowUsers/DenyUsers s’appliquent toujours. L’utilisateur xfer1 – ou plutôt les utilisateurs du groupe sftpusers – doivent être autorisés d’une manière ou d’une autre.
A noter aussi la beauté du geste avec le « %u » pour indiquer le nom de l’utilisateur.
Ensuite vous recharger le serveur SSH et testez les connexions SFTP et SSH-qui-passent-pas, sans oublier la distinction lecture/écriture.