bad ownership or modes for chroot directory "/var/www"

aliweb · 08-12-2017, 11:30 AM

I am using:

- Debian
- nginx
- php-fpm

Getting following error in auth.log when trying to connect to site using SFTP.

Quote:

fatal: bad ownership or modes for chroot directory "/var/www"

ls -ld of this directory shows this:

Quote:

drwxrwxr-x 4 root sftponly 4096 Aug 12 04:05 /var/www/

As you can see I have given full permission to group sftponly. The user through which I am connecting to SFTP is mysftpuser which is part of sftponly group.

If I do following then I can connect but cannot rename, edit, delete, overwrite any file or folder inside /var/www/

Quote:

sudo chmod 755 /var/www/

Here's my sshd_config setting

Quote:

Match group sftponly
ChrootDirectory /var/www
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

So in short sudo chmod 755 /var/www/ allows me to connect but only in READ only mode. sudo chmod 775 /var/www/ doesn't even allow me to connect.

How to fix this issue?

Turbocapitalist · 08-12-2017, 12:14 PM

Quote:

Originally Posted by aliweb

So in short sudo chmod 755 /var/www/ allows me to connect but only in READ only mode. sudo chmod 775 /var/www/ doesn't even allow me to connect.

That is correct. The manual page tells about that, scroll down to "ChrootDirectory" there:

Code:

man sshd_config

One option is to populate the /var/www/ directory as root with the files and subdirectories needed and chown those to your user or group. That will allow the files to be edited and the subdirectories worked in yet still retain the strict perminssions required by the SSH server.

However, instead I would recommend putting a subdirectory under /var/www/ and allowing your user to write to that. Leave /var/www/ for root.

Code:

sudo chown root:root /var/www/
sudo chmod u=rwx,g=rx,o=rx /var/www/

sudo mkdir /var/www/site1/
sudo chgrp sftponly /var/www/site1
sudo chmod u=rwx,g=rwxs,o=rx /var/www/site1/

Then in your SSH server's configuration file:

Code:

Match group sftponly
        ChrootDirectory /var/www/
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp -d site1

If you're going to have more than one virtual host on your web server, then I'd do it a little differently though.

aliweb · 08-12-2017, 01:08 PM

Quote:

Originally Posted by Turbocapitalist

That is correct. The manual page tells about that, scroll down to "ChrootDirectory" there:

Code:

man sshd_config

One option is to populate the /var/www/ directory as root with the files and subdirectories needed and chown those to your user or group. That will allow the files to be edited and the subdirectories worked in yet still retain the strict perminssions required by the SSH server.

However, instead I would recommend putting a subdirectory under /var/www/ and allowing your user to write to that. Leave /var/www/ for root.

Code:

sudo chown root:root /var/www/
sudo chmod u=rwx,g=rx,o=rx /var/www/

sudo mkdir /var/www/site1/
sudo chgrp sftponly /var/www/site1
sudo chmod u=rwx,g=rwxs,o=rx /var/www/site1/

Then in your SSH server's configuration file:

Code:

Match group sftponly
        ChrootDirectory /var/www/
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp -d site1

If you're going to have more than one virtual host on your web server, then I'd do it a little differently though.

Thanks for the quick reply. Yes I do already have a site folder inside www and I intend to host multiple sites. And since this is my own VPS hence I will only use one FTP user to connect to all sites instead of creating one for each site. I guess in this case I will use ForceCommand internal-sftp instead of ForceCommand internal-sftp -d site1 correct?

Turbocapitalist · 08-12-2017, 01:29 PM

If you have only one SFTP user for all sites then that would work. The -d option for the SFTP server subsystem just helps save time by putting the user into the right directory when they log in.

Code:

man sftp-server

I would encourage, however, to have different logins for the different people at least.

Also, since you are using SFTP to connect, the people working on the site can use various SFTP clients such as Nautilus, Dolphin, or SSHFS. Nautilus can open the remote site and treat it as a local folder, for example.

AwesomeMachine · 08-12-2017, 05:51 PM

You could move the chroot'ed directory out of the root path, and then use URL mapping to point to it.

Turbocapitalist · 08-13-2017, 01:23 AM

Quote:

Originally Posted by AwesomeMachine

You could move the chroot'ed directory out of the root path, and then use URL mapping to point to it.

I was expecting that they'd just change the Document Root for the virtual host. The Document Root can be any directory.

aliweb · 08-13-2017, 09:46 AM

Quote:

Originally Posted by Turbocapitalist

That is correct. The manual page tells about that, scroll down to "ChrootDirectory" there:

Code:

man sshd_config

One option is to populate the /var/www/ directory as root with the files and subdirectories needed and chown those to your user or group. That will allow the files to be edited and the subdirectories worked in yet still retain the strict perminssions required by the SSH server.

However, instead I would recommend putting a subdirectory under /var/www/ and allowing your user to write to that. Leave /var/www/ for root.

Code:

sudo chown root:root /var/www/
sudo chmod u=rwx,g=rx,o=rx /var/www/

sudo mkdir /var/www/site1/
sudo chgrp sftponly /var/www/site1
sudo chmod u=rwx,g=rwxs,o=rx /var/www/site1/

Then in your SSH server's configuration file:

Code:

Match group sftponly
        ChrootDirectory /var/www/
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp -d site1

If you're going to have more than one virtual host on your web server, then I'd do it a little differently though.

I did this and it fixed the problem!