File/Directory permissions for SFTP user

19,026

What I did was to create a home volume (let's call it /sftphome) for the sftpuser which has to be owned by root and has the following permissions and ownership:

/sftphome

drwxr-xr-x    root root

Then the sftp home directory for sftpuser also has to be owned by root:

/sftphome/sftpuser

drwxr-xr-x    root root

Then create a directory where sftpuser can upload and download:

/sftphome/sftpuser/upload

drwx------  sftpuser sftpuser

Of course make sure /sftphome is properly configured:

ChrootDirectory /sftphome

The end result of this is that when sftpuser logs into the sftp server this user is directed to /sftphome/sftpuser and then has to cd into upload in order to be able to upload and download files.

Share:
19,026

Related videos on Youtube

Big-Blue
Author by

Big-Blue

I'm a coder with way too less practical experience. I've got some knowledge in PHP, Java, Python, JavaScript & jQuery, HTML & CSS.

Updated on September 18, 2022

Comments

  • Big-Blue
    Big-Blue over 1 year

    After using the SSH quite a lot on my 1.5 week old Debian 6 VPS, I wanted to start uploading files through SFTP. I already tried that earlier, but with the root account, which isn't possible with SSH anymore due to security changes.

    So I've made a separate user, let's call him sftpuser for now, who belongs to the group sftp. He got a special entry in the sshd_config:

    Match Group sftp
        ChrootDirectory /var/www
        ForceCommand internal-sftp
        PasswordAuthentication yes
    

    So, he is lucky and doesn't need a keyfile to connect, but he is limited to /var/www. Well, that works, I can login perfectly and view all files there. But as they are owned by the root user, he can not upload anything, which renders him quite useless.

    On my journey through the wilds of file permissions I've read a lot of octal number combinations and weird workarounds, but nothing that quite fits. If I understand correctly, chmod can only be used to make a directory writeable to a certain user (root in this case), group (guess what, root in this case \o/) or others. The 'best' idea I had to fix this issue without breaking both PHP-FPM and nginx was to add sftpuser to the root group. Even though I thought it would be a bad idea, that shouldn't be able to cause much havoc, as sftpuser is chrooted and unable to open a shell. But that didn't work anyway, I was not able to write to any files there, not even with sftpuser in the root group.

    That said, I could really use help finding the right thing to use for my purpose. I don't expect a wall of text like I wrote here, just a little hint to point me in the right direction.

    • b0fh
      b0fh almost 12 years
      Beware that under linux, a process running as root can in most cases easily escape a chroot.
    • Big-Blue
      Big-Blue almost 12 years
      Yeah, I thought so, that's why I wrote it might be a bad idea. I removed sftpuser from the group right after the failed test.
    • DerfK
      DerfK almost 12 years
      I suggest that you take a look at Linux's ACLs. I've never used them myself, but this sounds like the perfect case for them. I think using a permission like u:sftpuser:rwx ought to do the trick, see a tutorial like sys-log.bencane.com/2012/05/…