Autorisations d'écriture utilisateur SFTP chrootées


10

J'ai une configuration avec des utilisateurs sftp uniquement:

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

J'obtiens le message suivant dans mon secure.log:

fatal: bad ownership or modes for chroot directory

Le mot clé match contient des éléments de sécurité ... les répertoires doivent appartenir à root et les répertoires doivent être chmod 755 (drwxr-xr-x). Ainsi, il est impossible pour un utilisateur d'avoir des autorisations d'écriture dans les dossiers, s'il est uniquement accessible en écriture à la racine de l'utilisateur et défini sur ben non accessible en écriture pour les groupes en raison de la sécurité de ssh.

Quelqu'un connaît un bon travail autour?


Les chrootutilisateurs ed possèdent-ils leur ChrootDirectory? Peuvent-ils y accéder?
John WH Smith

Réponses:


2

J'ai les mêmes paramètres sur notre serveur. Nous utilisons la même configuration de SSHD. Les répertoires personnels des utilisateurs appartiennent à root et dans les dossiers il y a documentset public_htmlappartiennent à des utilisateurs respectifs. Les utilisateurs se connectent ensuite à l'aide de SFTP et écrivent dans ces dossiers (pas directement dans la maison). Comme SSH n'est pas autorisé pour eux, cela fonctionne parfaitement. Vous pouvez ajuster les répertoires qui seront créés pour les nouveaux utilisateurs dans / etc / skel / (au moins dans openSUSE, je ne suis pas si familier avec les autres distributions).

Une autre possibilité serait ACL ( documentation openSUSE ) - il peut ajouter une autorisation d'écriture pour l'utilisateur respectif pour son répertoire personnel.


1
Pour moi, sur Debian Jessie (8.10), la définition d'une ACL au domicile de l'utilisateur ne fonctionne pas. Lorsque l'utilisateur essaie de se connecter avec SFTP, il obtientpacket_write_wait: Connection to 10.0.0.42 port 22: Broken pipe
Drew Chapin

7

Nous avons récemment trouvé une solution de contournement qui se présente comme suit:

/ etc / ssh / sshd_config:

...

Subsystem sftp internal-sftp

Match Group sftponly
    ChrootDirectory /home
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp

autorisations de répertoire:

root@server:~ # chown root:root /home
root@server:~ # chmod 111 /home
root@server:~ # chmod 700 /home/*

/homeSatisfait désormais aux exigences ChrootDirectorydes utilisateurs restreints et ne peut pas les répertorier, mais les sftponlyutilisateurs ne pourront pas se connecter si leurs répertoires personnels sont configurés comme d'habitude ( /home/$LOGNAME): dans l'environnement chrooté, leurs répertoires personnels ne sont pas à l'intérieur /homemais directement sous root ( /).

solution de contournement 1

Définissez les foyers des utilisateurs restreints sur leur apparence sous chroot:

root@server:~ # usermod -d /username username

mettre en cavé 1

Si l'un des utilisateurs non restreints ou un script d'administration utilise l'expansion tilde de bash comme ~usernameil se développera /usernamemaintenant, ce n'est pas ce que l'on veut dire.

L'administrateur qui crée les sftponlyutilisateurs doit également se rappeler d'utiliser la maison non par défaut. Résoluble avec un script. Que l'administrateur doit se rappeler d'utiliser.

solution de contournement 2

C'est une alternative à la précédente que nous avons fini par utiliser:

root@server:~ # ln -s . /home/home

C'est-à-dire créer un lien symbolique à l'intérieur /homevers son propre nom de répertoire. Maintenant, sous chroot /home/usernamepointe vers le même répertoire que sans chroot. Pour un utilisateur restreint connecté avec sftp, il apparaîtrait comme /username. Ce répertoire est accessible en écriture à son propriétaire (utilisateur restreint). L'utilisateur restreint ne peut pas répertorier ses répertoires parent ou personnel de ses frères et sœurs par leur nom.

La seule particularité d'un sftponlyutilisateur est sa participation au sftponlygroupe. Nous avons trouvé plus facile à gérer que la solution de contournement 1.

mises en garde 2

  1. Vous ne pouvez pas avoir un utilisateur nommé 'home' avec un répertoire personnel /home/home
  2. Vous devez être prudent avec les scripts qui traversent la /homehiérarchie et suivent les liens symboliques.

Salut artm ou tout autre lecteur, je sais que c'est un ancien article mais pourriez-vous m'aider à comprendre la solution de contournement 2 s'il vous plaît? J'ai un utilisateur (ftpuser) qui doit être emprisonné dans son répertoire personnel (/ home / ftpuser /), ce que je peux obtenir mais / home / ftpuser doit en avoir 755 bien sûr. J'ai besoin de ftpuser pour pouvoir créer des fichiers et des dossiers dans leur répertoire personnel. quel lien symbolique dois-je créer et quelle valeur mon ChrootDirectory doit-il avoir?
Blatant

4

Vous devez créer une structure dans le répertoire personnel de l'utilisateur, comme les répertoires d'entrée et de sortie. Ces répertoires doivent appartenir à l'utilisateur et il pourra y placer et récupérer des fichiers.


0

Vous devez créer la structure de répertoires suivante:

/ home / utilisateur

/ home / user / home / user <- le vrai répertoire auquel l'utilisateur aura accès

En option:

/home/user/.ssh/authorized_keys <- si vous voulez vous authentifier avec une clé publique


0

En référence à la section «autorisations de répertoire» dans la réponse de @artm (que je viens de tester). J'ai trouvé:

root@server:~ # chmod 111 /home <- Does not work

Il ne permet pas à la connexion sftp de fonctionner sur Ubuntu avec des autorisations d'exécution uniquement sur tout, c'est-à-dire 111.

Je l'ai trouvé:

root@server:~ # chmod 555 /home

Fonctionne avec une connexion à sftp avec les autorisations de lecture et d'exécution, c'est-à-dire 555. Je ne sais pas si debian vs les autres versions sont différentes, mais c'est ce qui fonctionne sur mes installations Ubuntu.


0

Lorsque vous créez un utilisateur, vous devez définir la propriété à l'aide chownde chaque répertoire pour chaque utilisateur.

Par exemple:

sudo chown usertest:groupsftp /home/rootsftp/usertest
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.