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?
chroot
utilisateurs ed possèdent-ils leurChrootDirectory
? Peuvent-ils y accéder?Réponses:
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
documents
etpublic_html
appartiennent à 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.
la source
packet_write_wait: Connection to 10.0.0.42 port 22: Broken pipe
Nous avons récemment trouvé une solution de contournement qui se présente comme suit:
/ etc / ssh / sshd_config:
autorisations de répertoire:
/home
Satisfait désormais aux exigencesChrootDirectory
des utilisateurs restreints et ne peut pas les répertorier, mais lessftponly
utilisateurs 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/home
mais directement sous root (/
).solution de contournement 1
Définissez les foyers des utilisateurs restreints sur leur apparence sous chroot:
mettre en cavé 1
Si l'un des utilisateurs non restreints ou un script d'administration utilise l'expansion tilde de bash comme
~username
il se développera/username
maintenant, ce n'est pas ce que l'on veut dire.L'administrateur qui crée les
sftponly
utilisateurs 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:
C'est-à-dire créer un lien symbolique à l'intérieur
/home
vers son propre nom de répertoire. Maintenant, sous chroot/home/username
pointe 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
sftponly
utilisateur est sa participation ausftponly
groupe. Nous avons trouvé plus facile à gérer que la solution de contournement 1.mises en garde 2
/home/home
/home
hiérarchie et suivent les liens symboliques.la source
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.
la source
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
la source
En référence à la section «autorisations de répertoire» dans la réponse de @artm (que je viens de tester). J'ai trouvé:
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é:
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.
la source
Lorsque vous créez un utilisateur, vous devez définir la propriété à l'aide
chown
de chaque répertoire pour chaque utilisateur.Par exemple:
la source