Question Comment puis-je chrooter les utilisateurs SSH uniquement de sftp chez eux?


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

J'ai créé un utilisateur appelé bob et l'a ajouté à un nouveau groupe appelé sftponly. Ils ont un répertoire personnel à /home/bob. J'ai changé leur coquille pour /bin/false pour arrêter les connexions SSH. Voici leur /etc/passwd ligne:

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

J'ai aussi changé le /etc/ssh/sshd_config d'inclure les éléments suivants:

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

Quand j'essaye de me connecter en tant qu'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 le ChrootDirectory ligne je peux SFTP dans, mais alors ils ont libre cours sur le serveur. J'ai trouvé que ChrootDirectory /home fonctionne, mais il leur donne toujours accès à n'importe quel répertoire d'accueil. J'ai explicitement essayé ChrootDirectory /home/bob mais ça ne marche pas non plus.

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

----MODIFIER-----

Bon alors je viens de regarder /var/log/auth.log et a 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 l'annuaire des utilisateurs. Voici la ls -h /home sortie:

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

111
2018-05-09 13:43


origine


Je crois ChrootDirectory /home/%u Peut être remplacé ChrootDirectory %h. - Franck Dernoncourt


Réponses:


Toute cette douleur est due à plusieurs problèmes de sécurité comme décrit ici. Fondamentalement, le répertoire chroot doit appartenir à root et ne peut pas être un accès en écriture de groupe. Charmant. Donc, vous devez essentiellement transformer votre chroot dans une cellule de détention et à l'intérieur cette 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.


111
2018-05-09 14:21



Merci vraiment utile. Deux problèmes cependant. 1.) Même si je ne peux pas écrire, je peux toujours parcourir tout le système de fichiers. 2.) Changer le shell en / bin / false empêche complètement le SFTP. Est-ce que je fais quelque chose de mal? - kim3er
Je vous remercie! Beaucoup d'autres articles sur ce sujet manquent ce détail, et certains font en sorte que le serveur ne peut pas accepter les connexions ssh (ce qui est nul lorsque vous êtes sur EC2 et ... c'est le seul moyen). - Tom Harrison Jr
kim3er: c'est parce que vous devez définir le shell de l'utilisateur sur / sbin / nologin - / bin / false désactive tout type d'accès.
Je voudrais également noter que tous les dossiers qui mènent à votre dossier chroot doivent appartenir à root. Dans cet exemple, /home devrait également être la propriété de root. - Shiki
Le 14.04, j'ai également dû changer le Subsystem sftp /usr/lib/openssh/sftp-server ligne à Subsystem sftp internal-sftp -f AUTH -l VERBOSE avant cela a fonctionné. - partofthething


Pour chrooter un répertoire SFTP, vous devez

  1. Créer un utilisateur et forcer root à 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. Changez l'emplacement du sous-système sur / etc / ssh / sshd_config:

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

    et créer une section utilisateur à la fin du fichier (ssh peut réapparaître s'il est placé après la ligne du sous-système):

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

52
2017-10-25 17:54



sans faire la dernière partie (créer une section utilisateur), rien n'a fonctionné! Je vous remercie - Sinan Erdem
cela ne semble pas fonctionner. dans votre exemple, l'utilisateur john est verrouillé à la /home/john annuaire. vous avez accordé 755 autorisations sur le répertoire. Le propriétaire a donc lu (4), écrit (2) et exécuté (1), et le groupe a lu (4) et exécuté (1). vous avez également défini le propriétaire et le groupe comme root, alors john appartient à d'autres. il a aussi lu et exécuté (4 + 1 = 5) alors. donc vous avez verrouillé john dans un répertoire où il n'a pas de privilèges d'écriture. Comment régler ceci? changer les privilèges pour 757 ou même 777 rompt le login. changer le groupe ou le propriétaire en client interrompt également la connexion. - Daniel
aussi à noter: dans / etc / ssh / sshd_config les configs sont lus dans l'ordre. Donc, si vous avez une règle pour les utilisateurs en général et que vous souhaitez en remplacer une, placez simplement la règle spécifique à l'utilisateur. - rwenz3l
Je veux chrooter un répertoire SFTP dans le dossier personnel d'un autre utilisateur. J'ai userx à /home/userx/sftproot/uploadset sftpuser à / home / sftpuse. J'ai mis chroot à /home/usex/sftproot appartenant à root: root et chmod 755. Le /home/usex/sftproot/uploads est édité par sftpuser: sftpuser. Je reçois la même erreur que la question initiale ci-dessus. Le chroot et tous les dossiers parent doivent-ils être la propriété de root: root pour que sftp fonctionne? - Primoz Rome


J'ai passé toute la journée à essayer d'obtenir un partage réseau sur mon framboise. Je voulais verrouiller l'utilisateur afin qu'il ne serait pas en mesure de naviguer dans l'ensemble du 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 l'ai fait fonctionner:

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

sudo useradd netdrive

Ensuite édité /etc/passwd et fait en sorte qu'il a /bin/false pour l'utilisateur donc la ligne était:

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

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

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

Propriétaire et autorisations du répertoire de base modifié:

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

Ok, après tout cela, j'ai pu me connecter en utilisant sshfs mais en 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 marchait sans autres changements. Notez que je n'ai que des autorisations en écriture pour le utilisateur, pas à la groupe autant de solutions en ligne. J'ai pu créer / supprimer / éditer / renommer des fichiers / dossiers sans problème.

Lors de l'accès en utilisant sshfs avec le netdrive utilisateur en raison de la configuration chroot je ne verrais que les choses stockées à l'intérieur du serveur /home/netdrive/ répertoire, parfait. Le répété /home/netdrive/home/netdrive/ la structure des répertoires est ce qui fait que cela fonctionne pour moi en ayant un propre chroot ssh accessible en écriture Solution.

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

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

Après avoir examiné les solutions ci-dessus (et beaucoup d'autres sur le net qui utilisaient même acl (listes de contrôle d'accès)) Je ne pouvais toujours pas le faire fonctionner car ce que je faisais ensuite était:

Les suivants ont fait NE PAS travaille pour moi:

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

Parce que le netdrive l'utilisateur n'était toujours pas en mesure d'écrire cela /home/netdrive/writable/ répertoire en dépit de posséder le dossier et avoir les autorisations. Alors j'ai fait:     sudo chmod 775 / home / netdrive / inscriptible / Et maintenant, je pouvais créer un répertoire et le supprimer, mais je ne pouvais pas le modifier car il était créé sans les autorisations en écriture pour les groupes. Voici ce que j'ai vu sur le net les gens utilisent acl réparer. Mais je n'étais pas content avec ça puisque je devais l'installer acl, puis configurez les points de montage, etc. Aussi, je ne sais pas pourquoi j'aurais besoin groupe l'autorisation d'écrire dans un dossier appartenant au même utilisateur.

Il semble que pour une raison quelconque la création /home/netdrive/home/netdrive et donner la propriété à la dernière netdrive dossier je pouvais faire tout fonctionner sans déconner groupe autorisations.


4
2017-07-18 17:58