Je veux donner à un client l'accès à mon serveur, mais je veux limiter ces utilisateurs à leurs répertoires personnels. Je vais lier-monter dans tous les fichiers que je veux qu'ils puissent voir.

J'ai créé un utilisateur appelé bobet l'a ajouté à un nouveau groupe appelé sftponly. Ils ont un répertoire personnel à /home/bob. J'ai changé leur shell /bin/falsepour arrêter les connexions SSH. Voici leur /etc/passwdligne:

bob:x:1001:1002::/home/bob:/bin/false

J'ai également changé le /etc/ssh/sshd_configpour inclure les éléments suivants:

Match Group sftponly
        ChrootDirectory /home/%u
        ForceCommand internal-sftp
        AllowTcpForwarding no

Quand j'essaie de me connecter comme eux, voici ce que je vois

$ sftp bob@server
bob@server's password: 
Write failed: Broken pipe
Couldn't read packet: Connection reset by peer

Si je commente la ChrootDirectoryligne, je peux utiliser le protocole SFTP, mais ils ont alors toute liberté sur le serveur. J'ai trouvé que cela ChrootDirectory /homefonctionne, mais cela leur donne toujours accès à n'importe quel répertoire personnel. J'ai explicitement essayé ChrootDirectory /home/bobmais ça ne marche pas non plus.

Qu'est-ce que je fais mal? Comment puis-je limiter bobà /home/bob/?

----MODIFIER-----

Bon alors j'ai juste regardé /var/log/auth.loget vu ceci:

May  9 14:45:48 nj sshd[5074]: pam_unix(sshd:session): session opened for user bob by (uid=0)
May  9 14:45:48 nj sshd[5091]: fatal: bad ownership or modes for chroot directory component "/home/bob/"
May  9 14:45:48 nj sshd[5074]: pam_unix(sshd:session): session closed for user bob

Je ne suis pas tout à fait sûr de ce qui se passe là-bas, mais cela suggère que quelque chose ne va pas dans le répertoire des utilisateurs. Voici la ls -h /homesortie:

drwxr-xr-x 26 oli      oli      4096 2012-01-19 17:19 oli
drwxr-xr-x  3 bob      bob      4096 2012-05-09 14:11 bob

Toute cette douleur est due à plusieurs problèmes de sécurité comme décrit ici . Fondamentalement, le répertoire chroot doit appartenir à rootet ne peut pas être un accès en écriture de groupe. Charmant. Il vous faut donc essentiellement transformer votre chroot en une cellule de stockage dans laquelle vous pouvez avoir votre contenu modifiable.

sudo chown root /home/bob
sudo chmod go-w /home/bob
sudo mkdir /home/bob/writable
sudo chown bob:sftponly /home/bob/writable
sudo chmod ug+rwX /home/bob/writable

Et bam, vous pouvez vous connecter et écrire /writable.

Pour chrooter un répertoire SFTP, vous devez

1. Créer un utilisateur et forcer la racine à en être propriétaire

   cd /home
   mkdir john
   useradd -d /home/john -M -N -g users john
   sudo chown root:root /home/john
   sudo chmod 755 /home/john
   

2. Modifiez l'emplacement du sous-système dans / etc / ssh / sshd_config:

   #Subsystem sftp /usr/lib/openssh/sftp-server
   Subsystem sftp internal-sftp
   

   et créez une section utilisateur à la fin du fichier (ssh peut mourir si il est placé après la ligne Subsystem):

   Match User john
       ChrootDirectory /home/john
       ForceCommand internal-sftp
       AllowTCPForwarding no
       X11Forwarding no
   

J'ai passé toute la journée à essayer d'obtenir un partage réseau sur ma framboise. Je voulais verrouiller l'utilisateur pour qu'il ne puisse pas naviguer dans tout le système de fichiers, pas d'accès de connexion ssh et je voulais avoir un accès en écriture au partage réseau.

Et voici comment je le fais fonctionner:

J'ai d'abord créé un utilisateur:

sudo useradd netdrive

Ensuite, édité /etc/passwdet vérifié /bin/falsepour l'utilisateur, la ligne était:

netdrive:x:1001:1004:Net Drive User,,,:/home/netdrive:/bin/false

J'ai édité /etc/ssh/sshd_configpour inclure:

Match User netdrive
  ChrootDirectory /home/netdrive
  ForceCommand internal-sftp
  AllowTcpForwarding no
  X11Forwarding no

Changement du propriétaire du répertoire de base et des autorisations:

sudo chown root:root /home/netdrive/
sudo chmod 755 /home/netdrive/

Ok, après tout cela, j’ai pu me connecter sshfsen mode lecture seule. Ce que je devais faire pour obtenir un dossier accessible en écriture:

sudo mkdir -p /home/netdrive/home/netdrive/
sudo chown netdrive:netdrive /home/netdrive/home/netdrive/
sudo chmod 755 /home/netdrive/home/netdrive/

C'était ça, ça a fonctionné sans autre changement. Notez que je ne dispose que d'autorisations d'accès en écriture pour l' utilisateur , et non pour le groupe, comme pour beaucoup d'autres solutions en ligne. J'ai pu créer / supprimer / éditer / renommer des fichiers / dossiers sans problèmes.

Lors de l'accès à l'aide sshfsde l' utilisateur netdrive en raison de la configuration chroot, je ne verrais que les choses stockées dans le /home/netdrive/répertoire du serveur , parfait. La /home/netdrive/home/netdrive/structure de répertoire répété est ce qui m'a permis de disposer d'une solution sch en écriture propre pour chroot .

Maintenant, je vais expliquer ci-dessous les problèmes que j'ai rencontrés:

Vous ne devriez probablement pas exécuter les paragraphes suivants :

Après avoir examiné les solutions ci-dessus (et de nombreux autres sur le réseau qui utilisaient même acl (listes de contrôle d'accès)), je ne pouvais toujours pas le faire fonctionner, car ce que j'ai ensuite fait était:

Ce qui suit n'a pas fonctionné pour moi:

sudo mkdir /home/netdrive/writable/
sudo chown netdrive:netdrive /home/netdrive/writable/
sudo chmod 755 /home/netdrive/writable/

Parce que l' utilisateur netdrive n'était toujours pas en mesure d'écrire dans ce /home/netdrive/writable/répertoire alors qu'il possédait le dossier et possédait les autorisations. Ensuite, j'ai fait: sudo chmod 775 / home / netdrive / write / Et maintenant, je pouvais créer un répertoire et le supprimer, mais je ne pouvais pas le modifier car il était créé sans autorisations de groupe en écriture. Voici ce que j'ai vu sur le net que les gens utilisent aclpour le réparer. Mais cela ne me convenait pas, car je devais installer acl, configurer des points de montage, etc. Je ne vois pas non plus pourquoi il me faudrait une autorisation de groupe pour écrire dans un dossier appartenant au même utilisateur.

Il semble que, pour quelque raison que ce soit, en créant /home/netdrive/home/netdriveet en donnant la propriété au dernier netdrivedossier, j'ai pu tout faire fonctionner sans modifier les autorisations de groupe .

J'ai suivi cet article mais cela n'a pas fonctionné. Il a commencé à fonctionner après avoir apporté ce changement (suggéré dans les réponses ci-dessus):

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

De plus, fait le répertoire de base root propre sous lequel j’avais un sous-répertoire en écriture (comme décrit ci-dessus).

La chose nouvelle et utile que je veux ajouter à cette réponse est que vous pouvez simplifier la configuration en spécifiant simplement% h comme répertoire de base de l'utilisateur:

ChrootDirectory %h

Je l'ai découvert grâce à ce lien.