Comment limiter l'accès des utilisateurs SSH à des répertoires spécifiques sous Ubuntu 24.04 (Guide Chroot SFTP)

Autoriser un prestataire à télécharger quelques fichiers ne devrait pas lui donner automatiquement accès à une session terminale avec une vue complète du serveur. Sous Ubuntu 24.04 LTS, OpenSSH permet de limiter un compte de transfert de fichiers à un répertoire spécifique grâce à une ChrootDirectoryrègle et au serveur intégré internal-sftp. Il est important de noter qu'il s'agit d'une restriction SFTP uniquement , et non d'un moyen simple de fournir un shell Bash pleinement fonctionnel mais isolé.

Ce guide explique ce que les paramètres protègent réellement, puis décrit une configuration réversible en huit étapes pour plusieurs comptes, chacun avec son propre répertoire. Les commandes utilisent un compte contractoret un hôte d' exempleserver.example.com ; remplacez-les par vos propres valeurs. Il s'agit d'exemples de configuration, et non de résultats de tests sur un serveur en production.

De quel type de restriction avez-vous réellement besoin ?

Trois mécanismes de contrôle sont souvent confondus. Les permissions Linux déterminent les fichiers qu'un compte peut lire ou modifier ; le répertoire personnel d'un compte définit son emplacement initial ; un chroot modifie la racine du système de fichiers présentée à un processus. Ces mécanismes ne sont pas interchangeables.

Idée reçue : définir /home/contractorun répertoire personnel confine l’utilisateur à cet emplacement. C’est faux. Un utilisateur shell standard peut accéder à n’importe quel répertoire accessible sur le système de fichiers. Si l’échange de fichiers est indispensable, privilégiez la méthode SFTP décrite ci-dessous plutôt que de masquer les répertoires via l’invite de commande.

Les documents OpenSSH ChrootDirectory, Matchet ForceCommanddans le manuel officiel sshd_config d'Ubuntu 24.04 .

Configurer un répertoire jail SFTP uniquement en huit étapes

Avant de modifier SSH à distance, conservez votre session d'administrateur ouverte et assurez-vous de disposer d'un accès console ou de récupération. Utilisez un compte non privilégié distinct pour les transferts ; n'ajoutez pas votre compte d'administrateur au groupe restreint.

1. Vérifiez OpenSSH et maintenez une session de récupération

Sur le serveur, installez OpenSSH si nécessaire, vérifiez le service et enregistrez la configuration principale. La documentation officielle du serveur Ubuntu décrit ces procédures d'installation et de configuration.

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.pre-sftp

Si vous ne pouvez administrer la machine que via SSH, ne fermez pas la session en cours pendant les modifications ou les tests. Consultez le guide de configuration du serveur OpenSSH d'Ubuntu avant de modifier le démon.

2. Créez un utilisateur dédié et un groupe d'accès SFTP

Un groupe est utile lorsque vous prévoyez plusieurs comptes restreints. Cet exemple attribue à chaque membre un environnement chroot distinct utilisant le %ujeton, qu'OpenSSH convertit en nom d'utilisateur de connexion. Le /uploadrépertoire personnel est destiné à se trouver dans le futur chroot ; il est donc inutile de créer un /uploadrépertoire au niveau de l'hôte.

sudo groupadd sftpclients
sudo adduser --home /upload --no-create-home --shell /usr/sbin/nologin contractor
sudo usermod -aG sftpclients contractor
id contractor

Le adduserprocessus peut vous demander de définir un mot de passe. Sur les installations qui désactivent l'authentification par mot de passe SSH, créez et autorisez plutôt une clé publique ; n'activez pas globalement la connexion par mot de passe simplement pour suivre un exemple. L' nologininterface en ligne de commande constitue une autre protection, mais internal-sftpc'est la commande imposée qui rend cette configuration utilisable uniquement pour le transfert. Testez cette combinaison sur votre propre infrastructure d'authentification.

3. Créer un répertoire chroot appartenant à root

C'est là que beaucoup de guides se trompent. OpenSSH exige que chaque élément du chemin chroot appartienne à root et ne soit pas accessible en écriture par d'autres utilisateurs ou groupes. Il ne faut jamais rendre le répertoire racine du chroot accessible en écriture par le compte SFTP.

sudo install -d -o root -g root -m 0755 /srv/sftp
sudo install -d -o root -g root -m 0755 /srv/sftp/contractor
namei -l /srv/sftp/contractor

Vérifiez également les composants existants/ ; /srvles commandes ci-dessus ne corrigent pas automatiquement les permissions parentes incorrectes. Si un composant est accessible en écriture par le groupe ou appartient à un utilisateur, corrigez son propriétaire et son mode uniquement après avoir vérifié si d’autres applications en dépendent.

4. Ajoutez un sous-répertoire accessible en écriture à l'intérieur de la prison.

Le compte peut écrire dans un sous-répertoire sans être autorisé à modifier le répertoire racine chroot. Créez un /srv/sftp/contractor/uploadfichier pour les fichiers du compte ; depuis un serveur SFTP, il apparaîtra comme suit/upload : .

sudo install -d -o contractor -g contractor -m 0750 /srv/sftp/contractor/upload
sudo stat -c '%U:%G %a %n' /srv/sftp/contractor /srv/sftp/contractor/upload

La propriété attendue diffère délibérément : root:rootpour le répertoire racine de la prison et contractor:contractorpour le dossier de téléchargement accessible en écriture. Évitez d'utiliser chmod 777une propriété qui exposerait inutilement les ressources et serait rejetée si elle était appliquée au répertoire racine de la prison.

5. Ajoutez une règle de correspondance à sshd_config

Ouvrez le fichier /etc/ssh/sshd_configet ajoutez le bloc suivant à la fin, après les directives et Matchblocs existants. Utilisez un éditeur de texte comme ` sudoeditopenssh` ou `openssh` sudo nano. Vérifiez d'abord les règles existantesMatch : si plusieurs blocs correspondants attribuent le même mot-clé, OpenSSH utilise la première occurrence applicable. Ubuntu traite également les fichiers situés sous `/etc/openssh` /etc/ssh/sshd_config.d/à partir d'un ancien répertoireInclude ; les règles qui s'y trouvent peuvent avoir une incidence sur la priorité.

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

Match GroupCible les membres de sftpclients. ChrootDirectoryplace chaque utilisateur sous /srv/sftp/USERNAME. ForceCommand internal-sftp -d /uploadexécute un service SFTP en interne et démarre dans le répertoire accessible en écriture. PermitTTY noEmpêche l'allocation de terminal, tandis que DisableForwarding yesdésactive les fonctionnalités de transfert SSH pour les connexions correspondantes.

Conservez la Subsystem sftpdirective globale fournie par Ubuntu, sauf si vous avez une raison particulière de la modifier ; la commande SFTP interne forcée ne nécessite pas le remplacement de cette ligne globale. N'ajoutez pas de directive globale supplémentaire Match Allsimplement pour terminer un bloc sans en comprendre les conséquences.

6. Vérifiez la syntaxe et les paramètres effectifs avant de recharger.

La réussite de l'analyse syntaxique ne prouve ni que les permissions de la prison sont correctes, ni que le compte visé correspond à la politique. Effectuez ces deux vérifications explicitement.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=contractor,host=localhost,addr=192.0.2.10 | grep -E '^(chrootdirectory|forcecommand|permittty|disableforwarding) '
namei -l /srv/sftp/contractor

La configuration effective doit indiquer le chemin chroot prévu, la commande SFTP forcée, l'allocation TTY désactivée et les restrictions de transfert. L'adresse donnée en exemple 192.0.2.10est uniquement à titre d'illustration ; si vous avez Matchdes règles dépendantes de l'adresse, remplacez-la par l'adresse source réelle du client. La -T -Csyntaxe est décrite dans le manuel sshd d'Ubuntu 24.04 .

En cas d'échec de la validation, corrigez la configuration avant de recharger SSH. Si les valeurs effectives sont inattendues, examinez les extraits de code inclus et l'ordre des blocs conditionnels existants, et pas seulement les dernières lignes modifiées.

7. Rechargez SSH et conservez votre accès administrateur

Après avoir effectué les vérifications, redémarrez le service SSH afin que les nouvelles connexions utilisent la stratégie modifiée. Maintenez la connexion administrateur active tout en ouvrant un second terminal pour vérifier que l'accès administrateur normal fonctionne toujours.

sudo systemctl reload ssh
sudo systemctl status ssh --no-pager

Un redémarrage complet peut également appliquer les modifications, mais un rechargement est préférable lorsqu'il est possible et que vous souhaitez éviter toute interruption inutile. L'affichage des commandes de service et les messages de journalisation varient selon l'hôte ; il est donc conseillé d'examiner le résultat réel plutôt que de supposer qu'un retour réussi à l'invite de commande garantit l'accès.

8. Test des transferts autorisés et de l'accès shell bloqué

Depuis un autre ordinateur, connectez-vous en tant qu'utilisateur restreint. Utilisez le nom d'hôte réel du serveur et un fichier de test approprié. Le premier répertoire SFTP devrait être `/etc/sfp` /upload, et la racine du chroot devrait apparaître comme `/etc/sfp` /plutôt que le chemin de l'hôte /srv/sftp/contractor.

sftp contractor@server.example.com
sftp> pwd
sftp> cd /
sftp> ls
sftp> cd /upload
sftp> put sample.txt
sftp> cd /etc
sftp> exit

Le chargement d'un fichier de test inoffensif devrait être autorisé /upload. L'accès au répertoire racine réel de l'hôte /etcne devrait pas être possible : le chroot définit une racine différente et /etcne serait accessible que si vous aviez délibérément créé ou exposé un tel répertoire à l'intérieur de l'environnement chrooté. Le texte exact de l'erreur du client n'est pas important.

ssh contractor@server.example.com

Il est impératif d'empêcher l'ouverture d'un shell SSH interactif classique pour ce compte. La connexion peut se fermer ou afficher un message relatif au protocole ; ne vous fiez pas à la formulation exacte. Si un shell s'ouvre, considérez la configuration comme non sécurisée et vérifiez l'appartenance au groupe, Matchla priorité des commandes et les paramètres sshd -T -Cde sortie avant d'utiliser ce compte.

Et si vous utilisiez des clés publiques SSH ?

/uploadL'authentification par clé publique fonctionne avec un environnement chroot SFTP, mais le fait de placer le répertoire personnel de l'utilisateur à un emplacement spécifique ~/.ssh/authorized_keyspeut empêcher l'existence du chemin par défaut en dehors de cet environnement. Une alternative pratique consiste à autoriser SSH à lire un fichier de clés contrôlé par l'utilisateur root avant de démarrer le chroot. Ajoutez ceci dans le même Match Group sftpclientsbloc si vous optez pour un stockage centralisé des clés :

    AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Créez ensuite un /etc/ssh/authorized_keys/contractorfichier contenant la clé publique autorisée du contractant, avec les droits d'administrateur et sans autorisation d'écriture pour le groupe ou les autres utilisateurs. Par exemple, après avoir copié en toute sécurité un fichier de clé publique vérifié nommé contractor.pubdans un répertoire de transit administratif :

sudo install -d -o root -g root -m 0755 /etc/ssh/authorized_keys
sudo install -o root -g root -m 0644 contractor.pub /etc/ssh/authorized_keys/contractor
sudo /usr/sbin/sshd -t

Ne copiez pas la clé privée sur le serveur. La configuration du chemin d'accès aux clés, les paramètres d'authentification par défaut et les vérifications de compte dépendent de votre politique SSH existante ; vérifiez l'accès par clé publique avant de désactiver une méthode d'authentification déjà fonctionnelle.

Les défaillances courantes et leur signification

Consultez les journaux avec ` sudo journalctl -u ssh -n 80 --no-pagerscp`. L'erreur exacte dépend des paramètres PAM, de la configuration SSH, de l'accès au système de fichiers et de la méthode d'authentification. OpenSSH 9.0 et versions ultérieures utilisent SFTP pour scples transferts standard par défaut, tandis que le mode hérité nécessite un shell, comme expliqué dans le manuel scp d'Ubuntu 24.04 .

Est-il possible de limiter un shell SSH interactif à un seul dossier ?

Pas avec un simple changement de répertoire personnel ni avec l'exemple SFTP ci-dessus. OpenSSH ChrootDirectorypeut également être utilisé pour les sessions shell, mais l'environnement d'exécution doit inclure un shell fonctionnel, ses bibliothèques partagées, les nœuds de périphériques requis et toutes les dépendances de commandes. Créer un tel environnement de manière sécurisée ne se limite pas à ajouter une ligne de configuration sshd_config. Il est facile de créer une configuration fragile ou trompeuse, surtout avec des commandes shell ou des points de montage arbitraires.

Si un utilisateur a réellement besoin de commandes interactives, il convient de spécifier précisément les commandes et les fichiers requis. Pour un ensemble de commandes restreint, utilisez des commandes distantes à portée limitée ou un point de terminaison d'application dédié. Pour des environnements indépendants plus étendus, envisagez un conteneur ou une machine virtuelle avec des montages de systèmes de fichiers explicites, des contrôles de privilèges et des restrictions réseau. Un environnement chroot seul ne remplace pas l'isolation complète du système, et ni chroot ni les permissions de fichiers Unix ne protègent contre un utilisateur privilégié capable de modifier le système sous-jacent.

Liste de vérification de sécurité avant d'accorder l'accès

• Le compte de transfert n'est pas un compte administrateur et appartient uniquement aux groupes nécessaires.
• Chaque composant menant à la prison est la propriété de la racine et n'est pas accessible en écriture au groupe ou au monde entier.
• L'emplacement de téléchargement accessible en écriture se trouve à l'intérieur de la prison, et non à la racine de la prison elle-même.
• L'utilisateur visé correspond à ChrootDirectory, ForceCommand internal-sftp, et le transfert a été désactivé dans la configuration effective.
• Un véritable transfert SFTP réussit, une tentative d'accès aux fichiers réservés à l'hôte échoue et l'accès normal au shell SSH est bloqué.
• La sauvegarde, la conservation, les quotas, la surveillance et la révocation des comptes sont gérés séparément ; un système de stockage de répertoires n’applique pas automatiquement ces politiques.

Pour plus de détails techniques, consultez la documentation de configuration d'OpenSSH pour Ubuntu 24.04 et le manuel du serveur SFTP d'Ubuntu . Ces instructions concernent Ubuntu 24.04 LTS ; les versions compilées des paquets et les extraits de code SSH existants peuvent modifier le comportement effectif. Par conséquent, seule la configuration et les tests de connexion effectués sur votre propre machine font foi.