Comment limiter l'accès des utilisateurs SSH à des répertoires spécifiques sous Ubuntu 24.04

La méthode la plus sûre pour limiter l'accès SSH à un répertoire spécifique sous Ubuntu 24.04 consiste à utiliser OpenSSH ChrootDirectoryavec `ssh-config` ForceCommand internal-sftp. Cette solution est idéale lorsque le compte ne nécessite que des transferts de fichiers. Elle offre à l'utilisateur une vue SFTP dont la racine du système de fichiers correspond au répertoire choisi, tout en bloquant l'accès à un shell interactif et le transfert SSH.

Si l'utilisateur a réellement besoin d'un shell classique, la décision est différente. Un shell interactif chrooté nécessite son propre binaire, ses bibliothèques, ses nœuds de périphérique et les fichiers nécessaires au sein de l'environnement chrooté. OpenSSH le documente explicitement. Pour la plupart des comptes d'hébergement mutualisé, de sauvegarde, d'agence, de fournisseur et de transfert de fichiers, un chroot limité au SFTP est bien plus simple et moins sujet aux erreurs. Pour les utilisateurs non fiables qui ont besoin d'un environnement de commande complet, un conteneur ou une machine virtuelle dédiée est généralement plus facile à gérer que la création manuelle d'un chroot.

Ce guide utilise Ubuntu 24.04 LTS et un utilisateur d'exemple nommé « utilisateur » alice. Cet utilisateur aura des droits d'accès restreints /srv/sftp/aliceet ne pourra écrire que dans le répertoire « / /filesetc ...

Avant de commencer : comprendre les règles de propriété

L'échec le plus fréquent de chroot est dû à un problème de permissions. OpenSSH exige que chaque élément du ChrootDirectorychemin appartienne à l'utilisateur root et ne soit pas accessible en écriture par le groupe ou d'autres utilisateurs . Cette condition est vérifiée systématiquement. Autrement dit, vous ne devez pas rendre /srv/sftp/alicele chemin accessible en écriture par l'utilisateur root alice.

Au lieu de cela, faites en sorte que le répertoire racine de la prison appartienne à root et créez un répertoire enfant accessible en écriture :

/srv/sftp/alice        root:root   755
└── files              alice:alice 755

Cette conception est conforme au comportement décrit dans le manuel d'Ubuntu 24.04sshd_config(5) . Ce même manuel précise qu'aucun internal-sftpfichier d'exécution supplémentaire n'est nécessaire dans l'environnement chroot, ce qui en fait la solution idéale pour un compte de transfert de fichiers restreint.

Étape 1 : Vérifiez que le serveur OpenSSH est installé.

Installez le package serveur si nécessaire :

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh.service

La documentation officielle d'OpenSSH pour Ubuntu utilise `openssh` openssh-serverpour le paquet démon et `openssh` ssh.servicepour la gestion des services. Consultez le guide OpenSSH pour Ubuntu Server .

S'il s'agit d'une machine distante et que SSH est votre seul accès à l'administration, conservez votre session d'administrateur ouverte pendant toute modification. Une configuration SSH incorrecte peut vous empêcher d'accéder à la machine.

Étape 2 : Créez un groupe et ajoutez l’utilisateur restreint

Créez un groupe pour les utilisateurs restreints. S'il aliceexiste déjà, ajoutez-la simplement :

sudo groupadd sftpusers
sudo adduser alice
sudo usermod -aG sftpusers alice
id alice

Si vous utilisez déjà des clés publiques SSH, continuez. La configuration chroot contrôle ce qui se passe après l'authentification ; elle ne vous oblige pas à passer de l'authentification par clé à l'authentification par mot de passe.

Une règle de groupe est généralement préférable à un Match Userblocage individuel pour chaque compte. Elle centralise les règles. Une règle par utilisateur reste utile lorsque différents utilisateurs doivent être soumis à des restrictions d'accès non liées.

Étape 3 : Créer une prison appartenant à l’utilisateur root et un sous-répertoire accessible en écriture

Créer la hiérarchie de répertoires :

sudo mkdir -p /srv/sftp/alice/files
sudo chown root:root /srv/sftp/alice
sudo chmod 755 /srv/sftp/alice
sudo chown alice:alice /srv/sftp/alice/files
sudo chmod 755 /srv/sftp/alice/files

Vérifier la propriété :

ls -ld /srv /srv/sftp /srv/sftp/alice /srv/sftp/alice/files
namei -l /srv/sftp/alice

Si /srvle /srv/sftpchemin d'accès est accessible en écriture par le groupe ou par l'utilisateur, corrigez-le également. OpenSSH vérifie tous les composants du chemin, et pas seulement le répertoire final.

Étape 4 : Ajouter une règle de correspondance dans sshd_config.d

La documentation actuelle du serveur Ubuntu recommande de conserver les paramètres SSH personnalisés dans /etc/ssh/sshd_config.d/un fichier séparé plutôt que de les intégrer au fichier principal du paquet. Créez un extrait de code :

sudo nano /etc/ssh/sshd_config.d/90-sftp-restricted.conf

Ajouter:

Match Group sftpusers
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp -d /files
    DisableForwarding yes
    PermitTTY no

Match all

%use développe en nom d'utilisateur authentifié et aliceest donc placé dans /srv/sftp/alice. L' -d /filesargument indique au serveur SFTP interne de démarrer dans le répertoire enfant accessible en écriture. DisableForwarding yesDésactive le transfert X11, agent, TCP et StreamLocal en une seule directive ; elle est spécifiquement documentée pour simplifier les configurations restreintes.

L'élément final Match allest important dans un extrait de code car il met fin au contexte conditionnel avant que la configuration ultérieure ne soit analysée.

Étape 5 : Choisir entre les restrictions par groupe et les restrictions par utilisateur

Pour plusieurs utilisateurs avec la même configuration, conservez la règle de groupe indiquée ci-dessus. Pour un compte unique et exceptionnel, utilisez plutôt un bloc spécifique à l'utilisateur :

Match User vendor1
    ChrootDirectory /srv/vendor/vendor1
    ForceCommand internal-sftp -d /incoming
    DisableForwarding yes
    PermitTTY no

Match all

Choisissez en fonction des frais administratifs :

Étape 6 : Validez la configuration SSH avant de redémarrer

Ne redémarrez jamais SSH immédiatement après avoir modifié le fichier. Commencez par exécuter le test de syntaxe recommandé par Ubuntu :

sudo sshd -t

L'absence de résultat signifie que la vérification de la syntaxe a réussi. Vous pouvez également consulter la configuration effective d'un utilisateur particulier :

sudo sshd -T -C user=alice,host=localhost,addr=127.0.0.1   | grep -E 'chrootdirectory|forcecommand|disableforwarding|permittty'

Vous devriez voir le chemin chroot attendu et la commande SFTP forcée. Ceci est particulièrement utile sous Ubuntu car les paramètres peuvent provenir à la fois de fichiers chroot /etc/ssh/sshd_configet de fichiers situés sous `/etc/ssh` /etc/ssh/sshd_config.d/. Ubuntu indique qu'OpenSSH utilise généralement la première valeur obtenue pour la plupart des directives ; il est donc plus sûr de vérifier la configuration effective que de supposer quel fichier prévaudra.

Étape 7 : Redémarrez SSH et testez avec SFTP

Appliquer la modification :

sudo systemctl restart ssh.service
sudo systemctl status ssh.service

Connectez-vous ensuite depuis un autre terminal :

sftp alice@server.example.com

Dans SFTP, test :

pwd
ls
put test.txt
ls -l

Avec la configuration ci-dessus, le répertoire SFTP initial devrait être /files. La barre oblique affichée par SFTP correspond à la racine du chroot, et non à la racine réelle du serveur.

Une tentative d'ouverture de session normale ne devrait pas produire un shell non restreint :

ssh alice@server.example.com

ForceCommand internal-sftpCe compte remplace la session demandée par le serveur SFTP intégré ; il est donc destiné au transfert de fichiers et non à l'exécution de commandes .

Étape 8 : Vérifier que l’utilisateur ne peut pas s’évader de prison.

Essayez de remonter au-dessus de la racine apparente et d'inspecter les chemins d'accès sensibles de l'hôte :

cd ..
ls /
ls /etc
ls /root

À l'intérieur du chroot, /cela représente /srv/sftp/alicel'hôte. Si vous n'avez créé aucun répertoire etcou rootà l'intérieur de cette prison, l'utilisateur ne peut pas accéder au véritable /etcou de l'hôte /root.

Testez également un chargement dans /files. Une configuration qui bloque l'échappement mais rend accidentellement l'ensemble de la jail en lecture seule est sécurisée mais inutile pour un compte de chargement.

Dépannage : « propriété ou modes incorrects pour le répertoire chroot »

Si la connexion échoue immédiatement, consultez le journal du service SSH :

sudo journalctl -fu ssh.service

Le guide OpenSSH d'Ubuntu recommande de consulter le journal du service SSH pour le dépannage. Si vous rencontrez une erreur de propriété ou de mode, examinez chaque répertoire parent :

namei -l /srv/sftp/alice

Le chemin du chroot doit appartenir à l'utilisateur root et ne doit pas être accessible en écriture par le groupe ou d'autres utilisateurs. Une erreur fréquente est la suivante :

sudo chown alice:alice /srv/sftp/alice

Ne résolvez pas le problème en affaiblissant les contrôles d'OpenSSH. Placez plutôt la zone accessible en écriture par l'utilisateur sous la racine du chroot :

sudo chown root:root /srv/sftp/alice
sudo chmod 755 /srv/sftp/alice
sudo chown alice:alice /srv/sftp/alice/files

Que se passe-t-il si l'utilisateur a besoin d'un accès shell SSH, et pas seulement d'un accès SFTP ?

ChrootDirectoryIl est également possible de l'utiliser avec un shell interactif, mais la configuration est alors beaucoup plus complexe. OpenSSH précise qu'un environnement chroot interactif nécessite au minimum un shell et /devdes nœuds de base, ainsi que tous les binaires, bibliothèques, fichiers de résolution de noms et autres dépendances requis par les commandes autorisées.

Pour un compte d'appliance strictement contrôlé, la création d'une telle jail peut se justifier. Pour un accès général aux commandes Linux, elle engendre souvent une charge de maintenance importante : les mises à jour de sécurité des outils et des bibliothèques doivent également être intégrées à la jail. Si votre besoin est simplement de permettre à un utilisateur d'exécuter des commandes tout en l'isolant de l'hôte, un conteneur, une machine virtuelle ou un service restreint dédié est généralement plus facile à auditer.

Améliorations de sécurité à ajouter

La restriction de répertoire ne constitue qu'une couche de protection. Pour les serveurs exposés à Internet, il faut également prendre en compte :

• Utilisez l'authentification par clé publique SSH pour les comptes humains et automatisés lorsque cela est possible.
• N’accordez pas sudol’accès aux utilisateurs disposant de droits restreints sur le transfert de fichiers.
• À conserver DisableForwarding yespour les comptes SFTP uniquement afin que la connexion SSH ne puisse pas être réutilisée pour des tunnels ou le transfert d'agents.
• Limitez les répertoires accessibles en écriture à la plus petite zone nécessaire au flux de travail.
• Vérification journalctl -u ssh.serviceet propriété des fichiers après l'ajout d'utilisateurs.
• Gardez une session d'administrateur ouverte pendant que vous testez les modifications de configuration SSH à distance.

Pour connaître le comportement précis des options ChrootDirectory`--config`, Match`--config` ForceCommand, `--restart` et ` --log` DisableForwarding, consultez le manuel de configuration du serveur OpenSSH d'Ubuntu 24.04 . Pour la configuration spécifique à Ubuntu, la validation, les commandes de redémarrage et la journalisation, reportez-vous à la documentation officielle du serveur OpenSSH d'Ubuntu .

En résumé

Si l'objectif est de limiter le partage de fichiers (téléversement et envoi) de ce compte SSH à un seul répertoire, utilisez un répertoire appartenant à l'utilisateur root ChrootDirectory, placez le contenu accessible en écriture dans un sous-répertoire appartenant à l'utilisateur et forcez l'accès chroot internal-sftp. Validez ce comportement sshd -tavant de redémarrer, puis testez le chemin de téléversement autorisé ainsi que les tentatives d'accès en dehors du chroot. Vous obtenez ainsi une barrière de sécurité réduite et compréhensible sans avoir à construire un environnement Linux complet à l'intérieur de ce dernier.