Configurez un service natif sécurisé : le serveur SFTP

Ce matin, lors du point d’équipe, Alex partage un nouveau besoin métier : plusieurs départements doivent pouvoir échanger des fichiers volumineux de manière simple et sécurisée. La solution retenue repose sur un service que vous connaissez déjà indirectement : SFTP.

La solution retenue est la mise en place d’un accès SFTP sur le serveur. Votre mission consiste à configurer ce service pour le rendre accessible aux collaborateurs concernés, tout en limitant strictement son périmètre d’utilisation.

Autoriser des transferts de fichiers vers un serveur n’est jamais un simple détail technique : il faut aussi s’assurer que les utilisateurs ne puissent accéder qu’aux espaces prévus pour eux.

Vous allez donc mettre en place un accès SFTP sécurisé, apprendre à restreindre ce qu’un utilisateur peut atteindre sur le système, puis diagnostiquer les erreurs de configuration susceptibles de bloquer les connexions.

Comprenez pourquoi confiner un accès SFTP

Créer un compte utilisateur dédié peut sembler suffisant pour séparer les usages. En réalité, ce compte reste un utilisateur Linux comme les autres : il conserve les permissions associées à son compte et peut parcourir les répertoires auxquels ces permissions lui donnent accès.

Dans un contexte professionnel, un accès SFTP doit respecter le principe du moindre privilège : l’utilisateur doit uniquement accéder à ce qui est nécessaire à sa mission.

Retenez cette logique : SSH/SFTP fournit le canal sécurisé, les permissions Linux définissent les actions autorisées, et le confinement limite le périmètre visible et accessible.

Restreignez les accès avec une configuration chroot

Pour limiter efficacement ce qu’un utilisateur SFTP peut voir sur le serveur, Linux propose un mécanisme de confinement appelé chroot (pour change root).

Le principe est simple : au moment de sa connexion, l’utilisateur est enfermé dans un répertoire précis du système de fichiers. Pour lui, ce dossier devient alors la racine apparente du serveur. Il peut naviguer à l’intérieur de cet espace, mais ne peut plus remonter vers le reste de l’arborescence.

Dans notre contexte, cela permet de créer un espace de dépôt isolé pour chaque collaborateur ou chaque équipe, sans exposer les autres répertoires du serveur.

Comme SFTP s’appuie directement sur SSH, ce confinement se configure dans le fichier principal du service SSH :  sshd_config  . Vous y utiliserez notamment la directive  ChrootDirectory  , qui indique le répertoire dans lequel l’utilisateur doit être confiné.

C’est ici qu’intervient une règle clé : le répertoire défini comme  ChrootDirectory  doit appartenir à  root  et ne doit pas être accessible en écriture par l’utilisateur confiné.

Cette contrainte existe pour une raison simple : si l’utilisateur pouvait modifier lui-même son environnement de confinement, il pourrait potentiellement compromettre l’isolation mise en place. SSH applique donc volontairement des règles strictes avant d’autoriser la connexion.

Alex insiste souvent sur ce point lors des déploiements :

Quand une configuration chroot échoue, le problème vient rarement du service SSH lui-même. Dans la majorité des cas, ce sont les permissions ou l’organisation des dossiers qui posent problème.

Retenez bien cette logique : dans un environnement SFTP, la sécurité dépend autant de la configuration du service que des permissions du système de fichiers.

Vous allez maintenant mettre en place ce confinement, structurer correctement les répertoires nécessaires et vérifier que l’utilisateur reste bien limité à son espace SFTP.

Dans cette vidéo, on a :

• modifié le fichiersshd_configpour configurer le confinement SFTP,

• ajouté les directives clésChrootDirectoryetForceCommand internal-sftp

• créé l’arborescence de répertoires avecmkdir

• ajusté les propriétaires avecchown

• appliqué les permissions nécessaires avecchmod

• redémarré le service SSH avecsystemctl restart ssh

• testé la connexion avecsftp

• vérifié le transfert de fichier avecputetls

Diagnostiquez un accès SFTP mal configuré

Alex reçoit un message du service comptabilité : impossible de déposer les documents attendus sur l’espace SFTP partagé. Pourtant, le serveur semble toujours accessible et aucun redémarrage n’a été signalé.

Vous tentez alors une connexion avec le compte concerné… mais l’accès échoue immédiatement.

Ce type de situation est extrêmement fréquent en administration Linux : le service SSH peut parfaitement fonctionner, tout en refusant certaines connexions à cause d’une erreur de configuration ou de permissions.

Dans un environnement SFTP avec confinement chroot, les problèmes proviennent souvent :

• d’un mauvais propriétaire sur un répertoire,

• d’une permission trop ouverte,

• ou d’une configuration incohérente danssshd_config.

C’est précisément ce qui rend ces incidents parfois déroutants : le service semble actif, mais une règle de sécurité empêche discrètement l’accès.

Votre rôle n’est donc pas de modifier la configuration au hasard, mais d’identifier méthodiquement ce que le système refuse.

Dans ce type de diagnostic, deux outils deviennent indispensables :

 Les logs SSH permettent notamment d’identifier :

• un répertoire de confinement modifiable par l’utilisateur,

• un mauvais propriétaire (rootattendu),

• ou une structure de dossiers incompatible avec les exigences du chroot.

Voyez maintenant comment reproduire ce type d’incident, analyser les indices laissés par SSH et corriger progressivement la configuration pour rétablir l’accès SFTP.

Dans cette vidéo, on a :

• diagnostiqué un échec de connexion SFTP malgré un service SSH actif avecsystemctl status ssh,

• utilisé journalctl pour identifier une erreur liée au confinement,

• vérifié les droits du répertoire/var/transferts_fichiersavecls -ld,

• corrigé la configuration bloquante avecchmod 755,

• relancé ou rechargé le service SSH,

• retesté la connexion SFTP,

• validé le bon fonctionnement du confinement SFTP.

À vous de jouer 

Contexte 

L'équipe marketing vient de recruter un nouveau prestataire externe. Alex a demandé à un technicien de lui préparer un accès SFTP confiné pour qu’il puisse transférer ses fichiers sans accéder au reste du système. 

Le compte utilisateur a bien été créé, le répertoire de dépôt existe et la configuration SSH a été modifiée. Pourtant, le prestataire vient de signaler que sa connexion est systématiquement refusée.

Alex se tourne vers vous :

Le service SSH fonctionne parfaitement pour nous, donc le problème ne vient probablement pas du serveur lui-même. À mon avis, quelque chose ne respecte pas les contraintes de sécurité du confinement SFTP. Je te laisse enquêter.

Votre mission consiste à reproduire l’incident, identifier la cause du refus dans les logs, puis corriger la configuration pour rétablir l’accès.

Préparation de l’environnement 

Pour reproduire la panne sur votre serveur Debian, appliquez la configuration suivante.

1. Ajoutez d’abord ces lignes à la fin du fichiersshd_config:

Match User sftp_test
ForceCommand internal-sftp
ChrootDirectory /var/sftp/dossier_partage

2. Créez ensuite l’utilisateur et le répertoire de confinement :

sudo useradd -m sftp_test
sudo mkdir -p /var/sftp/dossier_partage
sudo chown sftp_test:sftp_test /var/sftp/dossier_partage
sudo systemctl restart ssh

Consignes 

1. Testez la connexion SFTP avec sftp sftp_test@localhost (localhostdésigne votre propre serveur).

2. Vérifiez ensuite l’état du service SSH. Le service doit être actif malgré l’échec de connexion.

3. Consultez les logs du service SSH juste après votre tentative de connexion. Identifiez le message indiquant pourquoi le confinement SFTP est refusé.

4. Inspectez les permissions et surtout le propriétaire du répertoire utilisé commeChrootDirectory.

5. Corrigez l’anomalie en redonnant la propriété du répertoire de confinement àroot.

6. Redémarrez le service SSH si nécessaire, puis testez à nouveau la connexion SFTP.

Votre utilisateur doit désormais :

1. pouvoir se connecter,

2. rester confiné dans son espace dédié,

3. et être capable de déposer des fichiers sans accéder au reste du serveur.

En résumé

• Le protocole SFTP repose sur l’infrastructure sécurisée de SSH et permet de transférer des fichiers de manière chiffrée sans exposer un service distinct supplémentaire.

• Un accès SFTP professionnel doit respecter le principe du moindre privilège en limitant l’utilisateur aux seules ressources nécessaires à sa mission.

• Le mécanisme de confinement chroot, configuré dans le fichier/etc/ssh/sshd_configvia la directiveChrootDirectory, permet d’enfermer un utilisateur dans un répertoire dédié qui devient sa racine apparente.

• Le bon fonctionnement du confinement repose sur des permissions strictes, notamment un répertoire de chroot appartenant à root et non modifiable par l’utilisateur confiné.

• En cas d’échec de connexion SFTP malgré un service SSH actif, l’analyse des journaux avecjournalctl -u sshet la vérification des propriétaires et permissions permettent d’identifier et corriger méthodiquement l’erreur. 

Votre premier service natif est en place et sécurisé ! Vous maîtrisez désormais son déploiement et son diagnostic. Cependant, face à des applications complexes nécessitant des mises à jour fréquentes ou un déploiement sur plusieurs serveurs, cette méthode classique d'installation montre vite ses limites. Dans la prochaine étape, nous allons prendre du recul avec Alex et découvrir une approche plus moderne et incontournable pour faciliter vos déploiements : la conteneurisation applicative.