Argthtjtr

I have an Ubuntu server on Amazon running LAMP and WordPress site. I created a user called ftpuser that will connect to from FTP client via SFTP protocol to a /var/www/html/site/ and have rights on it.

1. I've created SSH keys, and the user connects to his /home/ftpuser/ folder.


2. 
   

   I've set

   
   
   

   usermod -m -d /var/www/html/site/ ftpuser
   
   

   
   



3. Copied /home/ftpuser/.ssh/ to /var/www/html/site. I set the ownership to ftpuser.



4. Added ftpuser to the www-data group.

But that does not work for me. The FTP user doesn't even connect. User actually connects only for the user’s initial home directory.

Do I have to change ownership of /var/www/html/site/ to a ftpuser, but in this case will the WordPress site stop working because www-data is set to run Apache, or I'm wrong?

In some manual it says:

chmod ug+w /var/www/html/site/

chmod g+s /var/www/html/site/

setfacl -d -m g::rwx /var/www/html/site/

I'm not sure that that will help me, and I don't want to get misconfigured the directories and stops the working website.

Any help please? Here are some infos about the directories:

ls -l /var/www/html/

drwxr-xr-x 12 www-data www-data 4096 Jan 29 13:16 site



ls -al /var/www/html/site/

drwx-w----  2 ftpuser  www-data  4096 Jan 29 13:16 .ssh



ls -l /var/www/html/site/.ssh/

-rw-r--r-- 1 ftpuser www-data  407 Jan 29 13:16 authorized_keys

-rw------- 1 ftpuser www-data 1675 Jan 29 13:16 id_rsa

-rw-r--r-- 1 ftpuser www-data  406 Jan 29 13:16 id_rsa.pub



getfacl /var/www/html/site/

getfacl: Removing leading '/' from absolute path names

# file: var/www/html/site/

# owner: www-data

# group: www-data

user::rwx

group::r-x

other::r-x



getfacl /var/www/html/site/.ssh/

getfacl: Removing leading '/' from absolute path names

# file: var/www/html/site/.ssh/

# owner: ftpuser

# group: www-data

user::rwx

group::-w-

other::---

Solved. In my case I also had to do:

chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

First, you say "the FTP user doesn't even connect." If the user is getting errors like Connection timed out, you most likely have a firewall/iptables problem and you'll need to fix that first. SFTP uses the same TCP port as SSH: by default that is 22.

Second, for security reasons, a regular user's home directory is usually owned by either the user itself (the normal case) or root (for special-purpose users). Also, in order to access their home directory, a user needs to have at least the x (directory access) permission to all the (grand)parent directories of their home directory, all the way to root. If these requirements are not satisfied, sshd may assume foul play and disallow logins (shell and SFTP) for that user. If the SFTP client successfully receives the server's host key, but then gets disconnected, this might be what's happening.

sshd also requires that the user's home directory, any (grand)parent directories all the way to the root directory, the .ssh sub-directory and the authorized_keys file in it are not writeable by other users, or else sshd will assume that any "authorized keys" are inserted by another malicious user and won't trust them. Putting the user's home directory in the middle of the HTTP server's subtree can make it more difficult to satisfy these requirements.

If the system has SELinux or other extra security measures in effect, trying to place an user's home directory into a non-standard location may require extra steps. In general, it will be much easier to just create a symbolic link to the ftpuser's home directory, pointing to the actual location of the site. The user will need to deal with one sub-directory, but that is usually tolerable.

I'd recommend first restoring the user's home directory location to normal:

usermod -d /home/ftpuser ftpuser

Then creating the symbolic link:

ln -s /var/www/html/site /home/ftpuser/site

Then start testing. First try to get the FTP user to at least connect: check the server's logs to see if a network connection gets established. Then make sure SSH key authentication works. Only after that it's time to worry about file permissions. It might be better for you to write a separate question about those.

And if you want the ftpuser to see only the contents of the web site and no other parts of the system, that's a special case: that's a chrooted SFTP account and it has some extra requirements, depending on the version of sshd used in the system. It might be easier to have ftpuser be jailed to their standard home directory, and then make the site accessible within the jail using a bind mount:

mkdir /home/ftpuser/site  #empty directory for a mount point

mount -o bind,rw /var/www/html/site /home/ftpuser/site

Similar to the symbolic link, this is just another, chroot-compatible way for the ftpuser to "see" the site directory as a sub-directory of their home directory: it won't affect the operations of the site at all.

(Symbolic links cannot point from the inside of a chroot jail to the outside world, but a bind mount can make parts of other filesystems accessible within the jail.)

When setting up a website directory tree to be maintained by non-root users, there may be a number of access categories to consider:

• a) Directories and files that you want to be readable by both the web server and the maintainers, but not modifiable by either of them: this might include privileged CGI scripts or other similar parts of the site's infrastructure.


• b) Directories and files that you want to be modifiable by the site maintainer(s), but only readable by the web server: this would be static content you want to be protected from defacement even if an intruder finds a new WordPress vulnerability or other attack vector.


• c) Directories and files that need to be modifiable by WordPress and/or other processes running as part of the web server, and also by the site maintainer(s). This would be essentially WordPress and all the content managed by it.


• d) Directories and files that are modifiable by WordPress only. By default, WordPress automatically makes sure its database files are protected like this.

Files and directories in categories a) and b) are easy: they can be owned by any user/group other than www-data. The only requirement is that they are readable by the www-data user, and the world-readable/accessible permission bits will cover that.

Files and directories in category a) might be owned by user root, group root and have permissions like -rw-r--r-- for regular files, -rwxr-xr-x for executable files and drwxr-xr-x for directories.

If your site includes files in category b), you may want to create a second group wwwadmin and make ftpuser a member of that group too. For this group, it is important that user www-data is not a member.

The files and directories in category b) would be owned by user ftpuser (or whoever), group wwwadmin, and permissions -rw-rw-r-- for regular files, -rwxrwxr-x for executable files and drwxrwxr-x for directories.

If Apache runs as the www-data user, any new files created by WordPress and/or any other site components will be owned by user www-data, group www-data. Since your ftpuser is already a member of the www-data group, you'll only need to ensure that in category c) all files have basic permissions rw-rw-r-- and any directories permissions drwxrwxr-x. That would mean adding the group write permission to all files owned by www-data and configuring Apache and/or WordPress to use umask 002. In Ubuntu, I think the Apache umask can be set in the /etc/apache2/envvars file. WordPress may override the web server default umask, so you might need to configure it separately.

To make all the files and directories owned by the www-data group have the right group access permissions, run this command:

find /var/www/html/site -group www-data -exec chmod g+rwX {} +

You may also want to add the setgid permission bit to all directories owned by the www-data user, to ensure that all new files and sub-directories added to them will automatically become owned by the www-data group even if it isn't the primary group of the user adding the file/directory:

find /var/www/html/site -type d -group www-data -exec chmod g+s {} +

This changes group permissions drwxrwxr-x to drwxrwsr-x, and removes the need for ftpuser to manually use chgrp www-data after adding any new files.

If you change the default umask setting for ftpuser to 002 (if it isn't that already), any new files they create will have group write access by default. That helps when modifying category c) files, and should not hurt with any other files in regular Ubuntu. Of course, their SFTP client may attempt to maintain the existing permissions of the files when transferring them, which may require some tweaking at the client side.

If you want to allow ftpuser to manipulate files of category d), the user needs to know that as long as they have write access to the directory the file is in, and the file is readable, they can always take up ownership of the file by making a copy of the file and then deleting the original.