Chrooted SFTP user write permissions

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
9
down vote

favorite
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





















  • Do the chrooted users own their ChrootDirectory ? Can they access it ?
    – John WH Smith
    Jul 31 '14 at 15:05














up vote
9
down vote

favorite
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





















  • Do the chrooted users own their ChrootDirectory ? Can they access it ?
    – John WH Smith
    Jul 31 '14 at 15:05












up vote
9
down vote

favorite
2









up vote
9
down vote

favorite
2






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









Adionditsak

2,01051421




2,01051421











  • 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










5 Answers
5






active

oldest

votes

















up vote
2
down vote



accepted










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




















  • 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 at 3:19

















up vote
7
down vote













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

















up vote
4
down vote













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



























    up vote
    0
    down vote













    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



























      up vote
      0
      down vote













      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






















        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',
        convertImagesToLinks: false,
        noModals: false,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: null,
        bindNavPrevention: true,
        postfix: "",
        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






























        5 Answers
        5






        active

        oldest

        votes








        5 Answers
        5






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes








        up vote
        2
        down vote



        accepted










        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




















        • 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 at 3:19














        up vote
        2
        down vote



        accepted










        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




















        • 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 at 3:19












        up vote
        2
        down vote



        accepted







        up vote
        2
        down vote



        accepted






        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









        Tilia

        10519




        10519











        • 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 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 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 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 at 3:19












        up vote
        7
        down vote













        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














        up vote
        7
        down vote













        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












        up vote
        7
        down vote










        up vote
        7
        down vote









        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









        artm

        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










        up vote
        4
        down vote













        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
























          up vote
          4
          down vote













          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






















            up vote
            4
            down vote










            up vote
            4
            down vote









            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









            YoMismo

            3,0381624




            3,0381624




















                up vote
                0
                down vote













                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
























                  up vote
                  0
                  down vote













                  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






















                    up vote
                    0
                    down vote










                    up vote
                    0
                    down vote









                    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 at 21:25









                    Fernando Ulisses dos Santos

                    1




                    1




















                        up vote
                        0
                        down vote













                        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


























                          up vote
                          0
                          down vote













                          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
























                            up vote
                            0
                            down vote










                            up vote
                            0
                            down vote









                            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 at 15:47

























                            answered Feb 20 at 18:41









                            willm

                            11




                            11



























                                 

                                draft saved


                                draft discarded















































                                 


                                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













































































                                Popular posts from this blog

                                How to check contact read email or not when send email to Individual?

                                Displaying single band from multi-band raster using QGIS

                                How many registers does an x86_64 CPU actually have?