Impossible de se connecter en SFTP sur un utilisateur après lui avoir donné les droits d'écriture

Support Debian
Tags: #<Tag:0x00007fb41b2fcf20>
#1

Bonjour,

J’ai un soucis avec le serveur SFTP que je configure sous Debian 11.
J’ai créé plusieurs utilisateurs avec chacun un répertoire dans un dossier /ftp, je peux m’y connecter tout fonctionne. Le problème étant que ces utilisateurs n’ont que les droits de lecture sur leur propre répertoire et non d’écriture (755).
Quand je fais un sudo chmod 775 /ftp/dsisftp par exemple, cela donne bien les droits d’écriture à l’utilisateur dsisftp sur son répertoire /ftp/dsisftp. Mais quand je veux m’y connecter comme d’habitude avec la commande sftp dsisftp@192.168.0.10 j’ai cette erreur qui survient :

client_loop: send disconnect: Broken pipe
Connection closed.
Connection closed

Est-ce que je dois changer les droits d’autres dossiers pour certains utilisateurs ? Est-ce que je dois modifier quelque-chose dans mon /etc/ssh/sshd_config ?

image

Merci d’avance pour vos réponses.

#2

Je pense qu’il y a incompréhension sur les propriétés et droits des fichiers.
755 signifie:

  • 7: l’utilisateur propriétaire a les droits lecture (4), + écriture (2) + exécution (1) sur le fichier/répertoire
  • 5: les utilisateurs membres du groupe propriétaire ont les droits de lecture (4) + exécution (1)
  • 5: tous les autres utilisateurs ont aussi les droits de lecture et d’exécution

Note: sur un répertoire, les droits d’exécution permettent de traverser le répertoire

Donc un fichier/répertoire avec les droits 755 est bien accessible en écriture à son utilisateur propriétaire.
Tu as donné les permissions de ton répertoire, mais pas son utilisateur / groupe propriétaire.

L’erreur broken pipe est très générique, cherche plutôt dans les logs du serveur juste après une tentative infructueuse (dans /var/log/syslog je pense)

1 J'aime
#3

Merci de ta réponse.

Le propriétaire du répertoire n’est pas dsisftp mais root:root, car si je ne fais pas ça je ne peux pas m’y connecter en SFTP.

D’accord, je vais regarder les logs merci.

#4
  • Reprend ta config SSH, après avoir créer un groupe dédié, tel que sshsftp.
  • et ajoute chacun de tes utilisateurs au groupe dédié
  • vérifie les droits sur le répertoire parent /ftp, il est absolument impératif qu’il appartienne à root, chmod 0755 suffit.
  • les sous-répertoires dédiés à chacun des utilisateurs doivent avoir les droits utilisateurs dédiés, chmod 0755 aussi. - et si je ne me trompe pas un chmod 0705 devrait fonctionner…

Quant à la config de sshd:

AllowGroups sshsftp

Match Group sshsftp
    ForceCommand internal-sftp
    ChrootDirectory %h

Pour autant que le HOME - répertoire personnel - de chaque utilisateur dédié soit bien déclaré…

Edit (à 14:36) : Pensez à redémarrer le service SSH !

#5

Ah, donc tu as ajouté l’utilisateur dsisftp au groupe root, vu qu’il peut écrire sur le répertoire après un chmod 775 ?
C’est pas le top, en termes de conception de sécurité.

A mon humble avis la solution à la fois la plus simple, et mieux en termes de sécurité, c’est de définir le répertoire $HOME des utilisateurs qui utiliseront le SFTP dans /ftp:

adduser --home /ftp/toto toto

Et quand tu te connectes au serveur en SFTP avec l’utilisateur toto, tu arrives dans le répertoire /ftp/toto sur lequel tu as tous les droits nécessaires.

Pour bien isoler les répertoires des utilisateurs (afin qu’ils ne puissent pas remonter l’arborescence des répertoires et regarder ce qu’il y a dans le $HOME du voisin) tu peux supprimer les permissions pour autres utilisateurs de ces répertoires (le dernier octet des permissions doit être à 0): chmod 770 /ftp/toto

Au lieu de tout ça, tu peux continuer à utiliser les directives ChrootDirectory (c’est aussi bien), mais il me semble bien qu’il est normal que ton utilisateur n’ait pas d’accès en écriture au répertoire /ftp/dsisftp, dans ce cas là, crée plutôt un sous-répertoire (par exemple fichiers) dans ce dossier, et transfère sa propriété à dsisftp:

mkdir -p /ftp/dsisftp/files
chown -R dsisftp:dsisftp /ftp/dsisftp/files
#6

Pour PengouinPdt :

Merci pour ta réponse,

/ftp appartient déjà à root, et je vais laisser 755 effectivement ça suffit je ne l’avais pas compris au départ.
J’ai fais ce qu’il fallait pour le groupe sshsftp mais ça ne résout pas mon problème.

Pour Sputnik93 :

Non je n’ai pas rajouté dsisftp au groupe root, et je n’ai pas laissé le chmod en 775 car sinon je ne peux pas me connecter en SFTP, j’ai donc laissé en 755.

Pour les HOME je l’ai déjà fais, il y a dans /ftp un répertoire pour chaque utilisateur et quand je me connecte à dsisftp par exemple, je me retrouve directement dans /ftp/dsisftp.

Je peux faire les get pour récupérer les fichiers qui sont dedans, mais quand j’essaye de faire un put j’ai l’erreur :

`remote open("le_fichier _que_je_veux_put") : Permission denied`

Je ne peux pas non plus supprimer des fichiers.

Et une fois connecter à un utilisateur je ne peux pas remonter l’arborescence donc tout est déjà bien isolé j’avais fais le nécéssaire.

D’accord je vais essayer ça pour le sous-dossier merci beaucoup !

#7

tu as bien tes utilisateurs dédiés affiliés au groupe ? getent group sshsftp ?
tu as bien redémarré le service ssh ?

PS : Si tu as bien fait selon le mode opératoire et la config SSH, que j’ai donné précédemment, ça doit fonctionner. Je fonctionne comme ça sur plusieurs serveurs, au fil du temps, depuis des années.
Parmi mes utilisateurs, certain a même un home différent des autres, et ça fonctionne autant. Il faut juste veiller à être sûr du home et des droits utilisateurs.
(chmod 755, ni plus ni moins, sauf à vouloir être encore plus restrictif).

Juste pour être sûr : que donne getent passwd dsisftp ?
(idem pour d’autres utilisateurs - que tu peux vérifier sans nous restituer)

#8

Pour Sputnik93 :

C’est parfait en créant un fichier /ftp/dsisftp/fichiers et en définissant dsisftp comme propriétaire, je n’ai plus de soucis de permissions non accordée sur les créations de répertoires et les put. En revanche je n’ai toujours pas la permission de supprimer quoi que ce soit en étant connecter en SFTP. Je ne veux pas le mettre en place pour l’instant mais au cas où j’en aurai besoin, j’aimerais comprendre le soucis. Je pense que c’est une autorisation à ajouter dans le sshd_config.

Pour PengouinPdt :

Oui j’avais tout fais et après avoir redémarré service sshd restart ça ne changeait pas, mais ce n’est pas un soucis ça fonctionne maintenant merci. Pour le chmod c’est vrai que 755 est le mieux je vais laisser comme ça.
Pour le getent passwd dsisftp ça ne fonctionne pas, mais j’imagine que c’est tant mieux c’était pour vérifier qu’on ne puisse pas récupérer le mot de passe de l’utilisateur c’est ça ? Merci je n’aurai pas pensé à essayer cette commande.

#9

Comportement anormal si et seulement si tu es connecté avec le bon utilisateur, dans son home, ayant les droits utilisateurs adéquats. Si c’est le cas, l’utilisateur peut logiquement faire des lectures, écritures de fichiers.

1/ ce n’est pas normal que ça ne fonctionne pas. Si le terminal ne retourne aucune information, c’est que l’utilisateur n’existe pas !
2/ cela affiche le résultat des informations liées à l’utilisateur, et non pas le mot-de-passe.
Tel que :

$ getent passwd myuser
myuser:x:1000:1000:myuser,,,:/home/myuser:/bin/bash

L’avant dernière colonne restitue le home de l’utilisateur en question :wink:
Elle peut directement être ciblée en utilisant l’ensemble de cette commande :
$ getent passwd your-user | awk -F ':' '{ print $6 }'

En passant, tu ne nous as pas non plus restitué la commande getent group sshsftp ! quid ?

Et, pour finir, si tu veux en savoir plus sur getent : man getent te permettra de découvrir les multiples possibilités de cet outil, bien pratique.

Ahhh, et dernier point, très important : Que restitue le log authlog ? (après une tentative de connexion).

#10

Au temps pour moi j’avais mal écris la commande :sweat_smile:

Voici les résultats :
image

#11

Et pour le auth.log après une connexion et déconnection voici les résultats :
image

#12

image

Et ceci pour la commande du groupe.

#13

Donc, dans l’immédiat, pour récapituler :

  • le HOME de dsisftp semble bien déclaré, et est bien /ftp/dsisftp
  • le group sftp a bien l’utilisateur dsisftp - et est pour l’instant le seul
  • l’authentification semble en effet se passer correctement

la seule chose que je ne vois pas est la config SSH du service :

  • quel est le nom du groupe marqué dedans ?
    grep -i group /etc/ssh/sshd_config devrait suffire :wink:
    mais nous restituer l’ensemble des deux écritures nous permettrait de vérifier qu’il n’y ait pas d’erreur de typos, par exemple…

Autre point : merci de simplement copier-coller les retours écrans, et non pas fournir des copies d’écrans - c’est mal les copies d’écrans dans ce contexte, car cela alourdit inutilement les posts, et n’apporte aucune lisibilité hors image, dont l’accessibilité de l’information.

#14

Le groupe utilisé est sftp, je ne l’ai pas appelé sshsftp.
La commande me retourne :
AllowGroups sftp
Match Group sftp

Je ne peux pas copier coller ce que me retourne la console, je suis en console web il n’y a pas de copier coller bi-directionnel… Car la remote console de vcenter ne fonctionne pas sur mon ordinateur. Donc soit je recopie ce que la commande me retourne au clavier, soit je met une capture d’écran.

#15

OK, très bien.
En espérant qu’il n’y ait pas d’erreur dans le reste de la config SSH lié à la déclaration Match Group et en espérant que les droits utilisateurs sur le répertoire /ftp, puis les sous-répertoires soient les bons - ça doit fonctionner, sans soucis.
Autrement, cela vient d’ailleurs - mais perso, je ne vois pas où et en quoi !

Une possibilité puisque tu as du réseau et est connecté sur le Net est d’utiliser un service de paste très léger, tel que 0x0.st, par exemple :

$ grep -i group /etc/ssh/sshd_config | tee sshd_config.txt
$ curl -F'file=@sshd_config.txt' https://0x0.st
  • copier l’URL retournée dans la console sur le forum
  • ensuite supprimer ledit fichier texte :wink:
#16

D’accord je ne connaissais pas ça, merci pour l’information !

1 J'aime