SFTP SERVEUR Linux Debian 11

Fermé
Nunux - 7 sept. 2022 à 21:35
mamiemando Messages postés 33073 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 16 avril 2024 - 8 sept. 2022 à 17:04

Bonjour (ou bonsoir),

On poste pour demander comment installer un serveur SFTP sur mon serveur Linux Debian.

J'ai vu des dizaines de tutos sur le net et je suis un peu perdu !

J'aimerai savoir comment faire pour faire cela , car je veux accéder aux fichiers et dossiers présents sur mon serveur. 

Merci pour vos réponses précieuses ! (⁠ ⁠◜⁠‿⁠◝⁠ ⁠)⁠♡

A voir également:

2 réponses

avion-f16 Messages postés 19243 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 8 avril 2024 4 496
7 sept. 2022 à 23:03

Bonjour,

Le plus simple est d'utiliser le serveur SSH inclus avec la plupart des distributions (OpenSSH). Si SSH est déjà activé, alors l'accès SFTP devrait fonctionner sans configuration additionnelle.

0

Merci pour votre aide mais si je dois cree des utilisateurs et je veux qu'ils est seulement l'autorisation d'aller dans 1seul répertoire ? Comment je fait ?

Merci 

0
avion-f16 Messages postés 19243 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 8 avril 2024 4 496 > Nunux
Modifié le 8 sept. 2022 à 16:42

Bonjour,

Il est possible de créer des utilisateurs systèmes sans accès shell, par exemple en les associant à « /sbin/nologin », et aussi de les restreindre via un "chroot".

Voir ici : https://tecadmin.net/how-to-create-sftp-only-user-in-ubuntu-debian/

Toutefois, les permissions se gèrent au niveau du modèle utilisateur/groupe de Linux. Si tu ne veux pas que des fichiers/dossiers sensibles soient accessibles par un utilisateur non autorisé, il faut régler le problème au niveau des permissions de ces fichiers/dossiers.

0
mamiemando Messages postés 33073 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 16 avril 2024 7 748
8 sept. 2022 à 17:04

Bonjour Nunux,

J'aimerais savoir comment accéder aux fichiers et dossiers présents sur mon serveur. 

Comme le dit avion-f16, sftp est une surcouche par dessus ssh qui permet de monter une arborescence de fichiers distante (et ainsi, d'en manipuler le contenu via un explorateur de fichiers comme pour un partage réseau classique).

Il suffit donc d'installer sur cette machine serveur un serveur ssh :

sudo apt install openssh-server

... et au niveau de ta machine cliente un client ssh :

sudo apt install openssh-client

Merci pour votre aide mais si je dois crée des utilisateurs et je veux qu'ils est seulement l'autorisation d'aller dans un seul répertoire ? Comment je fais ?

Droits utilisateurs lors d'un accès ssh ou sftp

En ce sens, un utilisateur qui se connecte en sftp est soumis aux mêmes contraintes que s'il s'était loggué en ssh. Il a donc les mêmes droits que cet utilisateur.

Exemple : si tu te loggues sur sftp://1.2.3.4 et que tu parviens à t'identifier, alors tu accèdes à l'arborescence de 1.2.3.4 avec les droits de l'utilisateur toto. En admettant que cet utilisateur soit raisonnablement configuré, tu as donc les droits en écriture sur /home/toto et /tmp mais pas le reste.

Si tu veux restreindre les droits d'accès de cet utilisateur, cela revient à contraindre les droits de toto sur ce serveur (sans même se demande s'il est connecté via ssh ou pas).

Rappels sur les droits Linux

Les droits sous Linux comportent trois triplets de droits RWX (Read Write eXecute) respectivement associé à un Utilisateur propriétaire, un Groupe propriétaire, et les autres (Others). Pour accéder à un dossier, il faut que l'utilisateur courant ait les droits en lecture et en exécution.

Pour savoir de quels droits dispose un utilisateur pour un fichier (au sens large, y compris un dossier) donné, il faut :

  • regarder les droits associés au fichier en question (voir ls -al), l'utilisateur propriétaire et le groupe propriétaire
    • Exemple : le fichier /etc/shadow appartient à l'utilisateur root, au groupe shadow, expose des droits en lecture écriture (rw-) à l'utilisateur propriétaire (donc root), des droits en lecture seule (r--) au groupe propriétaire (donc shadow) et aucun droits aux autres (---).
(mando@silk) (~) $ ls -al /etc/shadow
-rw-r----- 1 root shadow 1638  5 sept. 09:36 /etc/shadow
  • vérifier si son login correspond à celui de l'utilisateur propriétaire (voir résultats de whoami et ls -al)
    • Exemple : ici l'utilisateur courant est mando. La plupart du temps, le shell est configuré pour afficher l'utilisateur courant dans l'invite (devant le @). Dans notre exemple, comme mando n'est pas l'utilisateur propriétaire (root), et il n'a donc pas accès aux droits RW- dont disposerait l'utilisateur propriétaire pour manipuler /etc/shadow.
(mando@silk) (~) $ whoami
mando
  • s'il appartient au groupe propriétaire de ce fichier (voir résultats de groups et ls -al)
    • Exemple : ici l'utilisateur courant n'appartient pas au groupe propriétaire shadow, et donc n'a pas accès aux droits R-- dont disposerait un membre du groupe shadow.
(mando@silk) (~) $ groups
mando cdrom floppy sudo audio dip video plugdev input netdev lpadmin scanner bluetooth wireshark
  • Dans notre exemple, mando a donc les droits associés "aux autres", donc ---, c'est-à-dire le droit de ne rien faire sur ce fichier (ni lecture, ni écriture, ni exécution).

La seule exception a cette règle est l'utilisateur root qui a tous les droits.

Attention avant de changer des droits

De manière générale, il faut être très prudent sur comment modifier les droits associés à des fichiers, car on a vite fait de faire n'importe quoi :

  • Si le fichier est en dehors de /home, /mnt, ou /media : il s'agit d'un fichier associé à ton linux il ne faut pas changer les droits (donc ne pas utiliser les commandes chmod, chgrp, chown)
    • Si tu les relâches, tu ouvres un trou de sécurité potentiel
    • Si tu les resserres, tu risques de rendre le système partiellement ou complètement inutilisable pour les utilisateurs concernant.
      • Exemple : tu interdis à toto d'accéder à /bin : il ne pourra plus lancer un terminal.
  • Si le fichier est dans /home : chaque sous-dossier (e.g., /home/toto) appartient à un utilisateur. C'est à cet utilisateur (ici toto) de voir s'il veut autoriser les autres utilisateurs à accéder ou non à ses fichiers. C'est un cas où utiliser chmod peut avoir du sens.
  • Si le fichier est dans /media ou /mnt : ces dossiers contiennent des points de montage (périphériques, partage réseau). À moins que le système sous-jacent supporte une notion de droits linux (ce qui exclue par exemple une clé en FAT32) et soit accessible en écriture, les droits sont définis une fois pour toute au moment du montage pour l'ensemble des fichiers qu'il contient, et ces droits ne sont pas modifiables (même par root) sans remonter le système de fichiers avec d'autres droits.

La bonne philosophie est :

  • S'il s'agit de documents utilisateur, c'est à cet utilisateur de définir la bonne politique de droits
  • Sinon ne jamais relâcher des droits, en général c'est une erreur car cela ouvre un trou de sécurité. Les droits par défaut sont généralement les bons.
  • Si un utilisateur n'a pas suffisamment de droit, c'est soit qu'il y a une bonne raison, soit qu'il faut l'ajouter au groupe adéquat, soit qu'il doit passer sudo (et dans cas, il doit se demander si c'est normal qu'il doive devenir super utilisateur).

Retour à ton problème

Tous ces rappels préalables étant faits, supposons que toto veuille empêcher tata et titi d'accéder à son dossier personnel /home/toto (utilisateur propriétaire : toto ; groupe propriétaire toto).

  • Avec les droits unix  : Dans ce cas on applique au groupe (g) et aux autres (o) le retrait (-) des droits en lecture (r), écriture (w), et exécution (x) sur le dossier /home/tata ce qui s'écrit. Note que dans cas seul tata (et root car root à toujours tous les droits) peuvent entrer dans ce dossier. On a donc exclue toto mais également tous les autres utilisateurs (hormis root) !
chmod go-rwx /home/tata
  • Avec des ACL : les ACL sont nécessaires si on veut définir une politique de droits plus fine que celles que permettent de réaliser les droits unix. Dans ce cas, il faut installer et utiliser des ACL (voir ce tutoriel).

Bonne chance

0