Chrooted SFTP user write permissions












9















I have a setup with sftp only users:



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


I get the following message in my secure.log:



fatal: bad ownership or modes for chroot directory


With the match keyword there comes some security stuff with it... the directories need to be owned by root, and the directories need to be chmod 755 (drwxr-xr-x). So it makes it impossible for a user to have write permissions to the folders, if it is only writable to the user root and set to ben non-writable for groups due to ssh's security.



Someone know about a good work around?










share|improve this question























  • Do the chrooted users own their ChrootDirectory ? Can they access it ?

    – John WH Smith
    Jul 31 '14 at 15:05
















9















I have a setup with sftp only users:



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


I get the following message in my secure.log:



fatal: bad ownership or modes for chroot directory


With the match keyword there comes some security stuff with it... the directories need to be owned by root, and the directories need to be chmod 755 (drwxr-xr-x). So it makes it impossible for a user to have write permissions to the folders, if it is only writable to the user root and set to ben non-writable for groups due to ssh's security.



Someone know about a good work around?










share|improve this question























  • Do the chrooted users own their ChrootDirectory ? Can they access it ?

    – John WH Smith
    Jul 31 '14 at 15:05














9












9








9


2






I have a setup with sftp only users:



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


I get the following message in my secure.log:



fatal: bad ownership or modes for chroot directory


With the match keyword there comes some security stuff with it... the directories need to be owned by root, and the directories need to be chmod 755 (drwxr-xr-x). So it makes it impossible for a user to have write permissions to the folders, if it is only writable to the user root and set to ben non-writable for groups due to ssh's security.



Someone know about a good work around?










share|improve this question














I have a setup with sftp only users:



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


I get the following message in my secure.log:



fatal: bad ownership or modes for chroot directory


With the match keyword there comes some security stuff with it... the directories need to be owned by root, and the directories need to be chmod 755 (drwxr-xr-x). So it makes it impossible for a user to have write permissions to the folders, if it is only writable to the user root and set to ben non-writable for groups due to ssh's security.



Someone know about a good work around?







linux ssh centos sftp






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jul 31 '14 at 14:39









AdionditsakAdionditsak

2,08561421




2,08561421













  • Do the chrooted users own their ChrootDirectory ? Can they access it ?

    – John WH Smith
    Jul 31 '14 at 15:05



















  • Do the chrooted users own their ChrootDirectory ? Can they access it ?

    – John WH Smith
    Jul 31 '14 at 15:05

















Do the chrooted users own their ChrootDirectory ? Can they access it ?

– John WH Smith
Jul 31 '14 at 15:05





Do the chrooted users own their ChrootDirectory ? Can they access it ?

– John WH Smith
Jul 31 '14 at 15:05










6 Answers
6






active

oldest

votes


















2














I have same settings on our server. We use same config of SSHD. Users' home directories are owned by root and within them there are folders documents and public_html owned by respective users. Users then login using SFTP and write into those folders (not directly into home). As SSH is not allowed for them, it perfectly works. You can adjust which directories will be created for new users in /etc/skel/ (at least in openSUSE, I'm not so familiar with other distros).



Another possibility would be ACL (openSUSE documentation) - it can add write permission for respective user for his home directory.






share|improve this answer



















  • 1





    For me, on Debian Jessie (8.10), setting an ACL on the user's home does not work. When the user tries to login with SFTP, they get packet_write_wait: Connection to 10.0.0.42 port 22: Broken pipe

    – Drew Chapin
    Feb 18 '18 at 3:19



















7














We've found a workaround recently that goes like this:



/etc/ssh/sshd_config:



...

Subsystem sftp internal-sftp

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


directory permissions:



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


Now /home satisfies the requirements for ChrootDirectory and can't be listed by restricted users, but sftponly users will not be able to log in if their home directories are set up as usual (/home/$LOGNAME): under the chrooted environment their home directories aren't inside /home but directly under root (/).



workaround 1



Set restricted users' homes to how they appear under chroot:



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


caveate 1



If any of the unrestricted users or some administration script uses bash's tilde expansion like ~username it will expand to /username now, which isn't what is meant.



Also the admin that creates sftponly users has to remember to use non-default home. Solveable with a script. Which the admin has to remember to use.



workaround 2



This is an alternative to the previous one that we ended up using:



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


That is create a symlink inside /home to its own dirname. Now under chroot /home/username points to the same directory as without chroot. For restricted user logged in with sftp it would appear as /username. This directory is writable to its owner (restricted user). Restricted user can't list its parent or home directories of any of the siblings by name.



The only thing special about an sftponly user is its participation in the sftponly group. We found it easier to deal with than the workaround 1.



caveates 2




  1. You can't have user named 'home' with a home directory /home/home

  2. You have to be careful with scripts that traverse /home hierarchy and follow symlinks.






share|improve this answer


























  • Hi artm or any other readers, I know this is an old post but could you help me understand workaround 2 please? I have a user (ftpuser) that needs to be jailed to their home directory (/home/ftpuser/), this I can acheive but /home/ftpuser has to have 755 of course. I need the ftpuser to be able to create files nad folders in their home directory. what symlink do I need to create, and what value should my ChrootDirectory have please?

    – Blatant
    Feb 8 '17 at 18:48



















4














You need to create a structure inside the user's home directory, like in and out dirs. Those dirs should be owned by the user and there he will be able to put and get files.






share|improve this answer































    0














    You should create the following directory structure:



    /home/user



    /home/user/home/user <- the real dir that the user will have access



    Optionally:



    /home/user/.ssh/authorized_keys <- if you wanna to authenticate with a public key






    share|improve this answer































      0














      In reference to the 'directory permissions' section in the answer from @artm (which I just tested) ..
      I found:



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


      It doesn't allow the sftp connection to work on ubuntu with execute only permissions on everything i.e. 111.



      I found that:



      root@server:~ # chmod 555 /home


      Works with connection to sftp with the Read and Execute permissions i.e. 555. Not sure if debian vs other flavors are different, but that's what works on my ubuntu installs.






      share|improve this answer

































        0














        When you create a user, you have to set the ownership using chown to every dir for every user.



        For example:



        sudo chown usertest:groupsftp /home/rootsftp/usertest





        share|improve this answer










        New contributor




        Miguel Dueñas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.




















          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "106"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f147676%2fchrooted-sftp-user-write-permissions%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          6 Answers
          6






          active

          oldest

          votes








          6 Answers
          6






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          2














          I have same settings on our server. We use same config of SSHD. Users' home directories are owned by root and within them there are folders documents and public_html owned by respective users. Users then login using SFTP and write into those folders (not directly into home). As SSH is not allowed for them, it perfectly works. You can adjust which directories will be created for new users in /etc/skel/ (at least in openSUSE, I'm not so familiar with other distros).



          Another possibility would be ACL (openSUSE documentation) - it can add write permission for respective user for his home directory.






          share|improve this answer



















          • 1





            For me, on Debian Jessie (8.10), setting an ACL on the user's home does not work. When the user tries to login with SFTP, they get packet_write_wait: Connection to 10.0.0.42 port 22: Broken pipe

            – Drew Chapin
            Feb 18 '18 at 3:19
















          2














          I have same settings on our server. We use same config of SSHD. Users' home directories are owned by root and within them there are folders documents and public_html owned by respective users. Users then login using SFTP and write into those folders (not directly into home). As SSH is not allowed for them, it perfectly works. You can adjust which directories will be created for new users in /etc/skel/ (at least in openSUSE, I'm not so familiar with other distros).



          Another possibility would be ACL (openSUSE documentation) - it can add write permission for respective user for his home directory.






          share|improve this answer



















          • 1





            For me, on Debian Jessie (8.10), setting an ACL on the user's home does not work. When the user tries to login with SFTP, they get packet_write_wait: Connection to 10.0.0.42 port 22: Broken pipe

            – Drew Chapin
            Feb 18 '18 at 3:19














          2












          2








          2







          I have same settings on our server. We use same config of SSHD. Users' home directories are owned by root and within them there are folders documents and public_html owned by respective users. Users then login using SFTP and write into those folders (not directly into home). As SSH is not allowed for them, it perfectly works. You can adjust which directories will be created for new users in /etc/skel/ (at least in openSUSE, I'm not so familiar with other distros).



          Another possibility would be ACL (openSUSE documentation) - it can add write permission for respective user for his home directory.






          share|improve this answer













          I have same settings on our server. We use same config of SSHD. Users' home directories are owned by root and within them there are folders documents and public_html owned by respective users. Users then login using SFTP and write into those folders (not directly into home). As SSH is not allowed for them, it perfectly works. You can adjust which directories will be created for new users in /etc/skel/ (at least in openSUSE, I'm not so familiar with other distros).



          Another possibility would be ACL (openSUSE documentation) - it can add write permission for respective user for his home directory.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jul 31 '14 at 15:40









          TiliaTilia

          110119




          110119








          • 1





            For me, on Debian Jessie (8.10), setting an ACL on the user's home does not work. When the user tries to login with SFTP, they get packet_write_wait: Connection to 10.0.0.42 port 22: Broken pipe

            – Drew Chapin
            Feb 18 '18 at 3:19














          • 1





            For me, on Debian Jessie (8.10), setting an ACL on the user's home does not work. When the user tries to login with SFTP, they get packet_write_wait: Connection to 10.0.0.42 port 22: Broken pipe

            – Drew Chapin
            Feb 18 '18 at 3:19








          1




          1





          For me, on Debian Jessie (8.10), setting an ACL on the user's home does not work. When the user tries to login with SFTP, they get packet_write_wait: Connection to 10.0.0.42 port 22: Broken pipe

          – Drew Chapin
          Feb 18 '18 at 3:19





          For me, on Debian Jessie (8.10), setting an ACL on the user's home does not work. When the user tries to login with SFTP, they get packet_write_wait: Connection to 10.0.0.42 port 22: Broken pipe

          – Drew Chapin
          Feb 18 '18 at 3:19













          7














          We've found a workaround recently that goes like this:



          /etc/ssh/sshd_config:



          ...

          Subsystem sftp internal-sftp

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


          directory permissions:



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


          Now /home satisfies the requirements for ChrootDirectory and can't be listed by restricted users, but sftponly users will not be able to log in if their home directories are set up as usual (/home/$LOGNAME): under the chrooted environment their home directories aren't inside /home but directly under root (/).



          workaround 1



          Set restricted users' homes to how they appear under chroot:



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


          caveate 1



          If any of the unrestricted users or some administration script uses bash's tilde expansion like ~username it will expand to /username now, which isn't what is meant.



          Also the admin that creates sftponly users has to remember to use non-default home. Solveable with a script. Which the admin has to remember to use.



          workaround 2



          This is an alternative to the previous one that we ended up using:



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


          That is create a symlink inside /home to its own dirname. Now under chroot /home/username points to the same directory as without chroot. For restricted user logged in with sftp it would appear as /username. This directory is writable to its owner (restricted user). Restricted user can't list its parent or home directories of any of the siblings by name.



          The only thing special about an sftponly user is its participation in the sftponly group. We found it easier to deal with than the workaround 1.



          caveates 2




          1. You can't have user named 'home' with a home directory /home/home

          2. You have to be careful with scripts that traverse /home hierarchy and follow symlinks.






          share|improve this answer


























          • Hi artm or any other readers, I know this is an old post but could you help me understand workaround 2 please? I have a user (ftpuser) that needs to be jailed to their home directory (/home/ftpuser/), this I can acheive but /home/ftpuser has to have 755 of course. I need the ftpuser to be able to create files nad folders in their home directory. what symlink do I need to create, and what value should my ChrootDirectory have please?

            – Blatant
            Feb 8 '17 at 18:48
















          7














          We've found a workaround recently that goes like this:



          /etc/ssh/sshd_config:



          ...

          Subsystem sftp internal-sftp

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


          directory permissions:



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


          Now /home satisfies the requirements for ChrootDirectory and can't be listed by restricted users, but sftponly users will not be able to log in if their home directories are set up as usual (/home/$LOGNAME): under the chrooted environment their home directories aren't inside /home but directly under root (/).



          workaround 1



          Set restricted users' homes to how they appear under chroot:



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


          caveate 1



          If any of the unrestricted users or some administration script uses bash's tilde expansion like ~username it will expand to /username now, which isn't what is meant.



          Also the admin that creates sftponly users has to remember to use non-default home. Solveable with a script. Which the admin has to remember to use.



          workaround 2



          This is an alternative to the previous one that we ended up using:



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


          That is create a symlink inside /home to its own dirname. Now under chroot /home/username points to the same directory as without chroot. For restricted user logged in with sftp it would appear as /username. This directory is writable to its owner (restricted user). Restricted user can't list its parent or home directories of any of the siblings by name.



          The only thing special about an sftponly user is its participation in the sftponly group. We found it easier to deal with than the workaround 1.



          caveates 2




          1. You can't have user named 'home' with a home directory /home/home

          2. You have to be careful with scripts that traverse /home hierarchy and follow symlinks.






          share|improve this answer


























          • Hi artm or any other readers, I know this is an old post but could you help me understand workaround 2 please? I have a user (ftpuser) that needs to be jailed to their home directory (/home/ftpuser/), this I can acheive but /home/ftpuser has to have 755 of course. I need the ftpuser to be able to create files nad folders in their home directory. what symlink do I need to create, and what value should my ChrootDirectory have please?

            – Blatant
            Feb 8 '17 at 18:48














          7












          7








          7







          We've found a workaround recently that goes like this:



          /etc/ssh/sshd_config:



          ...

          Subsystem sftp internal-sftp

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


          directory permissions:



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


          Now /home satisfies the requirements for ChrootDirectory and can't be listed by restricted users, but sftponly users will not be able to log in if their home directories are set up as usual (/home/$LOGNAME): under the chrooted environment their home directories aren't inside /home but directly under root (/).



          workaround 1



          Set restricted users' homes to how they appear under chroot:



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


          caveate 1



          If any of the unrestricted users or some administration script uses bash's tilde expansion like ~username it will expand to /username now, which isn't what is meant.



          Also the admin that creates sftponly users has to remember to use non-default home. Solveable with a script. Which the admin has to remember to use.



          workaround 2



          This is an alternative to the previous one that we ended up using:



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


          That is create a symlink inside /home to its own dirname. Now under chroot /home/username points to the same directory as without chroot. For restricted user logged in with sftp it would appear as /username. This directory is writable to its owner (restricted user). Restricted user can't list its parent or home directories of any of the siblings by name.



          The only thing special about an sftponly user is its participation in the sftponly group. We found it easier to deal with than the workaround 1.



          caveates 2




          1. You can't have user named 'home' with a home directory /home/home

          2. You have to be careful with scripts that traverse /home hierarchy and follow symlinks.






          share|improve this answer















          We've found a workaround recently that goes like this:



          /etc/ssh/sshd_config:



          ...

          Subsystem sftp internal-sftp

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


          directory permissions:



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


          Now /home satisfies the requirements for ChrootDirectory and can't be listed by restricted users, but sftponly users will not be able to log in if their home directories are set up as usual (/home/$LOGNAME): under the chrooted environment their home directories aren't inside /home but directly under root (/).



          workaround 1



          Set restricted users' homes to how they appear under chroot:



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


          caveate 1



          If any of the unrestricted users or some administration script uses bash's tilde expansion like ~username it will expand to /username now, which isn't what is meant.



          Also the admin that creates sftponly users has to remember to use non-default home. Solveable with a script. Which the admin has to remember to use.



          workaround 2



          This is an alternative to the previous one that we ended up using:



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


          That is create a symlink inside /home to its own dirname. Now under chroot /home/username points to the same directory as without chroot. For restricted user logged in with sftp it would appear as /username. This directory is writable to its owner (restricted user). Restricted user can't list its parent or home directories of any of the siblings by name.



          The only thing special about an sftponly user is its participation in the sftponly group. We found it easier to deal with than the workaround 1.



          caveates 2




          1. You can't have user named 'home' with a home directory /home/home

          2. You have to be careful with scripts that traverse /home hierarchy and follow symlinks.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Sep 10 '15 at 6:09

























          answered Oct 10 '14 at 20:24









          artmartm

          44938




          44938













          • Hi artm or any other readers, I know this is an old post but could you help me understand workaround 2 please? I have a user (ftpuser) that needs to be jailed to their home directory (/home/ftpuser/), this I can acheive but /home/ftpuser has to have 755 of course. I need the ftpuser to be able to create files nad folders in their home directory. what symlink do I need to create, and what value should my ChrootDirectory have please?

            – Blatant
            Feb 8 '17 at 18:48



















          • Hi artm or any other readers, I know this is an old post but could you help me understand workaround 2 please? I have a user (ftpuser) that needs to be jailed to their home directory (/home/ftpuser/), this I can acheive but /home/ftpuser has to have 755 of course. I need the ftpuser to be able to create files nad folders in their home directory. what symlink do I need to create, and what value should my ChrootDirectory have please?

            – Blatant
            Feb 8 '17 at 18:48

















          Hi artm or any other readers, I know this is an old post but could you help me understand workaround 2 please? I have a user (ftpuser) that needs to be jailed to their home directory (/home/ftpuser/), this I can acheive but /home/ftpuser has to have 755 of course. I need the ftpuser to be able to create files nad folders in their home directory. what symlink do I need to create, and what value should my ChrootDirectory have please?

          – Blatant
          Feb 8 '17 at 18:48





          Hi artm or any other readers, I know this is an old post but could you help me understand workaround 2 please? I have a user (ftpuser) that needs to be jailed to their home directory (/home/ftpuser/), this I can acheive but /home/ftpuser has to have 755 of course. I need the ftpuser to be able to create files nad folders in their home directory. what symlink do I need to create, and what value should my ChrootDirectory have please?

          – Blatant
          Feb 8 '17 at 18:48











          4














          You need to create a structure inside the user's home directory, like in and out dirs. Those dirs should be owned by the user and there he will be able to put and get files.






          share|improve this answer




























            4














            You need to create a structure inside the user's home directory, like in and out dirs. Those dirs should be owned by the user and there he will be able to put and get files.






            share|improve this answer


























              4












              4








              4







              You need to create a structure inside the user's home directory, like in and out dirs. Those dirs should be owned by the user and there he will be able to put and get files.






              share|improve this answer













              You need to create a structure inside the user's home directory, like in and out dirs. Those dirs should be owned by the user and there he will be able to put and get files.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Jul 31 '14 at 15:39









              YoMismoYoMismo

              3,0761825




              3,0761825























                  0














                  You should create the following directory structure:



                  /home/user



                  /home/user/home/user <- the real dir that the user will have access



                  Optionally:



                  /home/user/.ssh/authorized_keys <- if you wanna to authenticate with a public key






                  share|improve this answer




























                    0














                    You should create the following directory structure:



                    /home/user



                    /home/user/home/user <- the real dir that the user will have access



                    Optionally:



                    /home/user/.ssh/authorized_keys <- if you wanna to authenticate with a public key






                    share|improve this answer


























                      0












                      0








                      0







                      You should create the following directory structure:



                      /home/user



                      /home/user/home/user <- the real dir that the user will have access



                      Optionally:



                      /home/user/.ssh/authorized_keys <- if you wanna to authenticate with a public key






                      share|improve this answer













                      You should create the following directory structure:



                      /home/user



                      /home/user/home/user <- the real dir that the user will have access



                      Optionally:



                      /home/user/.ssh/authorized_keys <- if you wanna to authenticate with a public key







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Feb 9 '18 at 21:25









                      Fernando Ulisses dos SantosFernando Ulisses dos Santos

                      11




                      11























                          0














                          In reference to the 'directory permissions' section in the answer from @artm (which I just tested) ..
                          I found:



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


                          It doesn't allow the sftp connection to work on ubuntu with execute only permissions on everything i.e. 111.



                          I found that:



                          root@server:~ # chmod 555 /home


                          Works with connection to sftp with the Read and Execute permissions i.e. 555. Not sure if debian vs other flavors are different, but that's what works on my ubuntu installs.






                          share|improve this answer






























                            0














                            In reference to the 'directory permissions' section in the answer from @artm (which I just tested) ..
                            I found:



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


                            It doesn't allow the sftp connection to work on ubuntu with execute only permissions on everything i.e. 111.



                            I found that:



                            root@server:~ # chmod 555 /home


                            Works with connection to sftp with the Read and Execute permissions i.e. 555. Not sure if debian vs other flavors are different, but that's what works on my ubuntu installs.






                            share|improve this answer




























                              0












                              0








                              0







                              In reference to the 'directory permissions' section in the answer from @artm (which I just tested) ..
                              I found:



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


                              It doesn't allow the sftp connection to work on ubuntu with execute only permissions on everything i.e. 111.



                              I found that:



                              root@server:~ # chmod 555 /home


                              Works with connection to sftp with the Read and Execute permissions i.e. 555. Not sure if debian vs other flavors are different, but that's what works on my ubuntu installs.






                              share|improve this answer















                              In reference to the 'directory permissions' section in the answer from @artm (which I just tested) ..
                              I found:



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


                              It doesn't allow the sftp connection to work on ubuntu with execute only permissions on everything i.e. 111.



                              I found that:



                              root@server:~ # chmod 555 /home


                              Works with connection to sftp with the Read and Execute permissions i.e. 555. Not sure if debian vs other flavors are different, but that's what works on my ubuntu installs.







                              share|improve this answer














                              share|improve this answer



                              share|improve this answer








                              edited Apr 28 '18 at 15:47

























                              answered Feb 20 '18 at 18:41









                              willmwillm

                              11




                              11























                                  0














                                  When you create a user, you have to set the ownership using chown to every dir for every user.



                                  For example:



                                  sudo chown usertest:groupsftp /home/rootsftp/usertest





                                  share|improve this answer










                                  New contributor




                                  Miguel Dueñas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                  Check out our Code of Conduct.

























                                    0














                                    When you create a user, you have to set the ownership using chown to every dir for every user.



                                    For example:



                                    sudo chown usertest:groupsftp /home/rootsftp/usertest





                                    share|improve this answer










                                    New contributor




                                    Miguel Dueñas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                    Check out our Code of Conduct.























                                      0












                                      0








                                      0







                                      When you create a user, you have to set the ownership using chown to every dir for every user.



                                      For example:



                                      sudo chown usertest:groupsftp /home/rootsftp/usertest





                                      share|improve this answer










                                      New contributor




                                      Miguel Dueñas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.










                                      When you create a user, you have to set the ownership using chown to every dir for every user.



                                      For example:



                                      sudo chown usertest:groupsftp /home/rootsftp/usertest






                                      share|improve this answer










                                      New contributor




                                      Miguel Dueñas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.









                                      share|improve this answer



                                      share|improve this answer








                                      edited Jan 10 at 0:34









                                      cryptarch

                                      72310




                                      72310






                                      New contributor




                                      Miguel Dueñas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.









                                      answered Jan 9 at 21:54









                                      Miguel DueñasMiguel Dueñas

                                      1




                                      1




                                      New contributor




                                      Miguel Dueñas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.





                                      New contributor





                                      Miguel Dueñas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.






                                      Miguel Dueñas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.






























                                          draft saved

                                          draft discarded




















































                                          Thanks for contributing an answer to Unix & Linux Stack Exchange!


                                          • Please be sure to answer the question. Provide details and share your research!

                                          But avoid



                                          • Asking for help, clarification, or responding to other answers.

                                          • Making statements based on opinion; back them up with references or personal experience.


                                          To learn more, see our tips on writing great answers.




                                          draft saved


                                          draft discarded














                                          StackExchange.ready(
                                          function () {
                                          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f147676%2fchrooted-sftp-user-write-permissions%23new-answer', 'question_page');
                                          }
                                          );

                                          Post as a guest















                                          Required, but never shown





















































                                          Required, but never shown














                                          Required, but never shown












                                          Required, but never shown







                                          Required, but never shown

































                                          Required, but never shown














                                          Required, but never shown












                                          Required, but never shown







                                          Required, but never shown







                                          Popular posts from this blog

                                          How to make a Squid Proxy server?

                                          第一次世界大戦

                                          Touch on Surface Book