You should never have to run a website from within your home directory. EVER. You would otherwise have to give the web server the ability to traverse through /home/ to see the directory structure, but also into /home/$USER/ (your user's home directory, where we can try and see what else exists in your user directory), as well as any other subfolders in there. A poorly-configured or misconfigured or unpatched web server can cause massive data leakage this way, or loss of credentials and such which would put your personal data and logins on different things at risk. The symlink approach you are using doesn't help either for the same reason as trying to give Apache permissions to read /home/andre/www/moodle – the web server has to be able to traverse your home directory to get to the location that the symlink in /var/www/html points to, which still poses that security risk.
Firstly, use sudo cp -r /home/andre/www/moodle/ /var/www/html/. This will copy your files to /var/www/html, and keep it away from your own home directory. We'll then redo the permissions so you and the web server can access everything in that directory, and give your user full read/write to all the files and directories. Then, you will only ever have to work out of /var/www/html for your site.
This is in effect, four steps, after you copy your data back to /var/www/html:
- Give Apache access to the folders and files, so it can serve the site without 403 errors.
- Give your user 'owner' over the files and folders, and give yourself read/write on all of the files and folders, as well as the ability to traverse the directories.
- (Optional but recommended) Set it up such that any files or folders created from hereon in the entirety of the directory structure has the group set to be
www-data. - (Optional) Final security cleanup, where we set up permissions so you and the web server can see the site data, but other users cannot access files or the directory structure for the site.
(1) Allow Apache access to the folders and the files.
sudo chgrp -R www-data /var/www/html
sudo find /var/www/html -type d -exec chmod g+rx {} +
sudo find /var/www/html -type f -exec chmod g+r {} +
This recursively sets the 'group' to be www-data for the folders and files. This then gives the web server permission to recurse and get access to the site document root directories structure (+x for directories only). It then also ensures the web server has read permissions for all files, so site data can be received.
There may be some cases where you have to give the web server write permission to a file, or to a directory – this can be achieved by doing sudo chmod g+w /var/www/html/PATH (where PATH is the path to the file or folder in the directory structure where you need to apply the write permissions for the web server).
NOTICE: There are a lot of cases where this may expose 'secure' information about a site configuration (such as database access credentials, etc.), and you should remove 'other' access permissions to that data on those individual files or directories with the following: sudo chmod o-rwx /var/www/html/FILEPATH (replacing FILEPATH with the path relative to the /var/www/html folder for the file).
Note also that you may have to re-run these commands in the future if 'new files' get 403 issues, in order to give correct permissions to the web server to keep being able to access files and folders that are created or copied in and aren't getting the www-data group set correctly.
(2) Give your owner read/write privileges to the folders and the files, and permit folder access to traverse the directory structure.
sudo chown -R USER /var/www/html/
sudo find /var/www/html -type d -exec chmod u+rwx {} +
sudo find /var/www/html -type f -exec chmod u+rw {} +
Replace USER in the first command with your own username!
We do three things here. First, we set your user to be the "Owner" of all the files and directories in /var/www/html. Next, we set read and write permissions on the folders, and permit you to access the folders to go into them (the +x item on the directory items). We then set all the files to have read/write permissions for the owner, which we just set.
(3) (Optional) Make sure every new file after this is created with www-data as the 'access' user.
sudo find /var/www/html -type d -exec chmod g+s {} +
This sets the "set gid" bit for the group on the directories. Files and folders created inside these directories will always have www-data as the group, permitting the web server access.
(4) (Optional) Final security cleanup, if you don't want other users to be able to see the data
We need your user to see the directories and files. We need the web-server to do so too. We may not want other system users (except root) to see the data. So lets not give them that access, and make it so only your user and the web server can see the data.
sudo chmod -R o-rwx /var/www/html/
NOTE: You will not have to re-run this at a later time, or edit the permissions for the 'other' category of permissions here. If the 'other' users can't get to /var/www/html/ (they don't have the necessary +x bit on /var/www/html to traverse the filestructure and directory structure, nor the +r bit to read the file lists), then the permissions on items underneath that directory for other users or groups isn't really going to matter too much.
There is a slightly less invasive solution to this, as well, though it's not guaranteed to work for all new files, nor is it guaranteed to work on all file systems, involving file access control lists. This lets you leave ownership of the files with www-data for things, but gives you effective owner rights, for all intents and purposes, even though you don't personally own the files.
This solution is a little less invasive, and lets you have a directory and all files within owned by www-data:www-data or root:www-data but also give yourself access. It uses Access Control Lists, which lets you have multiple users have permissions without setting up individual groups. This also lets the root or www-data system users own files, but also lets you add additional permissions on a case-by-case basis, and fine-tune permissions for certain users so they can read things but not edit, and such.
Assuming we're still working with /var/www/html/, and we don't want snooping users other than us and the system (and root of course) to see our data, we'll need to do the following things:
- Give ownership back to the webserver system user
www-data.
sudo chown -R www-data:www-data /var/www/html
- Recursively give you read/write on the files, while giving other users (excluding
www-dataandrootof course) no access to the files.
sudo find /var/www/html -type f -exec setfacl -m u:YOURUSERNAME:rw -m other::--- {} \;
- Recursively give yourself read/write/traverse on the directories, remove access to the folders for other users (excluding
www-dataandroot) and set this as the 'default' ACL for new files in the directories.
sudo find /var/www/html -type d -exec setfacl -d -m u:YOURUSERNAME:rwx -m o::--- {} \;
- We also need to set the
setgidbit for all directories, so that if you create a file the webserver can still access it aswww-datavia group permissions.
sudo find /var/www/html -type d -exec chmod g+x {} \;
And now you've got access to all the directories, and you didn't have to take access away from www-data which helps as the webserver can still create files everywhere as it needs to (such as PHP based frontends having their own cache directories and such needing to be created and written to for proper operation).
The only caveat: If you manually create new files, you need to chown them accordingly to give ownership to the webserver. That's a simple sudo chown www-data:www-data filename, and the access control lists should still let you have effective owner rights to the file.
There are multiple cases where I've had to do this as a sysadmin for some type of non-standard access without changing the owners of a given file. This works, but has its own headaches, as not every file system supports file access lists.
Follow
CommunityBot
1
answered May 4, 2016 at 14:22
68k2929 gold badges168168 silver badges230230 bronze badges
2
@AndréCarvalho
+xto files would give executable permissions, and we don't want PHP files executed, necessarily, through the PHP command line or as an executable on the server itself – we want them processed by the PHP parser in the web server (and we don't need the PHP files to have+xfor the PHP parser to read and process them). Directories need+xin order to permit traversal through the directories – that is, if a directory is not+xand I am not root, I can't get into the directory, which is the issue you had with Apache not working with your symlinks and your home directory.– Thomas Ward♦
1
@AndréCarvalho
www-datais a system group – it's not a group for standard users to be in.– Thomas Ward♦
1
@JunaidQadirShekhanzai Impossible to provide since people's settings differ greatly from their environments they need, and many other factors. Such a 'shell file' would be impossible to produce given that there are optional components. I could try and make a Python script that could do this, but we still run into things like system restrictions, optional tasks, varying paths, etc.
– Thomas Ward♦
1
@T.Todua that's not what I said. I said that you should never run a site out of (read: from within) your "home" directory – that is, you should not run anything in
/home/USER/...on a webserver. You've misread and misunderstood the meaning of the words I use./var/www/*is a relatively 'safe' place to run websites out of because that's a dedicated folder/space for it. However,/var/www/htmlis NOT safe because that's written to by webservers on install and such, and leads to clobbering of important data (so use/var/www/SUBDIRECTORYwith individual site subdirs instead)– Thomas Ward♦
1
I've adjusted the wording for clarity.
– Thomas Ward♦
https://www.liquidweb.com/kb/configure-apache-virtual-hosts-ubuntu-18-04/
How to Configure Multiple Sites with Apache
Posted on July 29, 2020 by Justin Palmer | Updated: March 10, 2021
Category: Tutorials | Tags: A2Ensite, Apache2, Configuration, Hosts, Site, Virtual Host
Reading Time: 3 minutes
If you are hosting more than one site on a server, then you most likely use Apache’s virtual host files to state which domain should be served out. Name based virtual hosts are one of the methods used to resolve site requests. This means that when someone views your site the request will travel to the server, which in turn, will determine which site’s files to serve out based on the domain name. Using this method you'll be able to host multiple sites on one server with the same IP. In this tutorial, we’ll show you how to set up your virtual host file for each of your domains on an Ubuntu 18.04 VPS server.
Preflight
- Login in as root
Step 1: Make a Directory for Each Site
You’ll create a directory for each site that you’ll be hosting, within the /var/www folder. This location newly created location is also dubbed the document root location; you’ll need to set this path later in the configuration file. Sub the domain.com and domain2.com for your domain names.
mkdir -p /var/www/**domain.com**/public_html
mkdir -p /var/www/**domain2.com**/public_html
Step 2: Set Folder Permissions
chmod -R 755 /var/www
Step 3: Set up an Index Page
To see a home page you’ll want to make sure the index.html file is created for each domain. Something as simple as “testing for domain.com” can be set within this file.
vim /var/www/**domain.com**/public_html/index.html
testing for domain.com
Save and quit by hitting the Escape button and typing :wq
Repeat the steps for your second domain, using the command below.
vim /var/www/**domain2.com**/public_html/index.html
Step 4: Copy the Config File for Each Site
Copy the default configuration file for each site, this will also ensure that you always have a default copy for future site creation.
cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/domain.com.conf
cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/domain2.com.conf
Step 5: Edit the Config File for Each Site
At the bare minimum, you’ll adjust and add the highlighted lines within the <VirtualHost *:80> and tags.
Note
ServerAlias is the alternative name for your domain, in this case and in most, you’ll put www in front of the domain name so people can view the site by either www or non www (ServerName).
vim /etc/apache2/sites-available/domain.com.conf
<VirtualHost *:80>ServerAdmin admin@example.comServerName domain.comServerAlias www.domain.comDocumentRoot /var/www/domain.com/public_htmlErrorLog ${APACHE_LOG_DIR}/error.logCustomLog ${APACHE_LOG_DIR}/access.log combined</VirtualHost>
Quit and Save with :wq. Repeat this process for your domain2.com.conf file, be sure to update your ServerName, ServerAlias and DocumentRoot for your second domain.
Step 6: Enable Your Config File
Out of the box, your server is set to read the default 000-default.conf file. But, in our previous step we made a new config file for each domain. So, we will need to disable the default file.
a2dissite 000-default.confTo have your server mapped to your domains you’ll need to enable each of your newly made .conf files.
a2ensite domain.com.conf
a2ensite domain2.com.conf
We restart the Apache service to register our changes.
systemctl restart apache2
To activate the new configuration, you need to run:
systemctl reload apache2
Step 7: Verify Apache Configurations
After starting Apache you now can view that the configurations are working by either editing your /etc/host file on your computer or by editing your domain's DNS.
After either one of these aspects are set, you'll be able to visit your website in a browser to see the index.html pages set in Step 3.
Liquid Web customers enjoy 24/7 support at the tip of their fingertips with our blazing fast servers. If you find yourself stuck on a step our support team is knowledgeable on Apache configurations and can assist!
https://devanswers.co/configure-sftp-web-server-document-root/
How To Configure SFTP for a Web Server Document Root
Last updated on July 12th, 2022 | 55 replies
SFTP is the favourite these days because of its robust security model and easier setup than traditional FTP and FTPS. In this guide we will configure SFTP to allow users to upload to the web server document root.
Introduction
This guide assumes your web document root is the default for Apache and Nginx in /var/www/html. If you followed one of our previous guides on setting up virtual hosts, your document root may be located in /var/www/example.com/public_html. Just make sure you have the correct document root and update commands in this guide to match.
This guide was tested on Ubuntu Server 20.04, 18.04 and 16.04, though it should also work with other Debian-based distributions without issue. If you are using CentOS, just substitute www-data in this guide for apache or nginx. Any issues, please let me know in the comments.
I have provided two different methods in this guide for setting up SFTP access to your document root:
- Method One is a simple setup where you just add your SFTP user to the
www-datagroup. - Method Two is far more secure and recommend if you want to limit where
www-datahas write access. I have included a special section for WordPress users and best security practises. See step 5.5: WordPress and www-data.
Regardless of the method you choose, Step 1, 2 and 3 below are the same.
This article also includes a section for WordPress users and best security practices.
1. Install SSH
SFTP is built upon the SSH transport layer and should be installed on most Linux server distributions by default. If it isn’t , you can install with:
sudo apt install ssh
2. Configure SSH
Change the Subsystem to internal-sftp in sshd_config.
sudo nano /etc/ssh/sshd_config
Scroll to the bottom of the file and comment out the line Subsystem sftp by adding # before it and then add Subsystem sftp internal-sftp below it.
/etc/ssh/sshd_config
#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp
This tells sshd to use SFTP server code built into sshd instead of running sftp-server, which is now redundant and only kept for a backward compatibility.
Restart the sshd service for changes to take affect.
sudo service sshd restart
3. Create SFTP User
It’s not recommended that you use the root account or any account with sudo privileges to upload files to the web server document root. For this reason, you should create a new user that only has SFTP access to the document root.
In this guide, we are calling the SFTP user webdev – you can call this whatever you want. If you plan to give SFTP access to multiple users across different document roots, consider a naming scheme like username_domain_com. For example john_devanswers_co. This will make it easier to keep track of all your SFTP users.
For the purposes of this guide, we will name the SFTP user webdev.
sudo adduser webdev
Generate a password and press enter to accept all defaults.
Two SFTP Configuration Methods
I am providing two different methods in this guide because there are some people who just want a quick and easy method to access the document root with SFTP, and others who want a more advanced security setup (which I use). It might be worth reading through both methods to see which one suits your needs.
-
- You just want a quick and simple method to give one or multiple SFTP users access to the document root by adding them to the
www-datagroup. - You already have a live, busy site running on the document root and don’t want to risk accidentally taking it down by setting restrictive permissions in Method Two.
- You need to install a CMS from scratch such as WordPress before setting up more restrictive permissions in Method Two.
- You just want a quick and simple method to give one or multiple SFTP users access to the document root by adding them to the
Method Two: Better Security and SFTP User Management
- You want the best security possible for your document root.
- You already have your CMS such as WordPress installed and running, and now want to lock it down.
- You want to restrict where
www-datacan write to. - You have multiple developers that need write access to multiple document roots hosted on your server.
4. Method One: Quick Setup
Using this method with the least amount of configuration, we will create a Match User directive in the SSH config and add your SFTP user to the www-data group.
4.1. Add Match User Directive in SSH Config
Restrict the user webdev to the document root and also disable their SSH access – we only want them to be able to log in over SFTP. We can do this by adding a Match User directive in the SSH config file.
Begin by opening sshd_config.
sudo nano /etc/ssh/sshd_config
Scroll down to the bottom of the SSH config file and add your new Match User directive.
Make sure that ChrootDirectory is the directory above your document root. For example, if your document root is /var/www/html/, then the ChrootDirectory is /var/www/.
If you followed one of our previous guides on hosting multiple domains on Apache or Nginx, your document root may be located in /var/www/mydomain.com/public_html, in that case, your ChrootDirectory would be /var/www/mydomain.com/.
Note you can add multiple users here separated by a comma, e.g. Match User webdev, webdev2, webdev3
Note: ForceCommand internal-sftp will force SFTP access only and not allow this SFTP user to log in via SSH.
/etc/ssh/sshd_config
Match User webdev
ChrootDirectory /var/www/
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no
PasswordAuthentication yes
Save and exit (press CTRL + X, press Y and then press ENTER)
Test SSH config before restarting.
sudo sshd -t
If no errors, restart the sshd service for changes to take affect.
sudo service sshd restart
4.2. Add SFTP User to www-data
Add your SFTP user webdev to the www-data group.
sudo usermod -a -G www-data webdev
Note: Linux groups do not take affect until the user logs out and in again. If you are already logged in as this user in your FTP client, close the program completely and then log in again.
4.3. Set Directory Permissions
SFTP is very strict when it comes to chroot directory permissions and if they are not set correctly, you will not be able to log in, so please follow these instructions carefully.
The chroot is usually the directory above your document root. For example, by default /var/www/ is the chroot and /var/www/html is the document root. Another example, if your document root is one directory deeper such as /var/www/domain.com/public_html, then your chroot is /var/www/domain.com.
- The chroot directory *and all of its parents* must not have group or world write capabilities, otherwise SFTP log in will fail with fatal: bad ownership or modes for chroot directory component “/var/www/”. In other words, you must make sure both
/var/and/var/www/are set to755. (not775, which gives group write permissions). - The chroot directory *and all of its parents* must be owned by
root, otherwise SFTP log in will fail with fatal: bad ownership or modes for chroot directory component “/var/www/”. In other words, you must make sure both/var/and/var/www/are both owned byroot. - If your chroot directory is not
/var/wwwbut, for example,/var/www/domain.com, then you will need to apply these permissions androotownership to that folder as well and all of its parents!
Firstly, let’s check permissions and ownership for /var/ – they should be 755 and root by default.
sudo ls -ld /var/
Output:
drwxr-xr-x 14 root root 4096 Jul 30 02:24 /var/
If they do not match above, set permissions and ownership below.
sudo chmod 755 /var/
sudo chown root:root /var/
Now let’s apply the same permissions and ownership for your chroot. Assuming that your chroot is /var/www/, ensure that the directory is set to 755.
sudo chmod 755 /var/www/
Ensure your chroot directory is owned by root.
sudo chown root:root /var/www/
To check permissions for this directory:
sudo ls -ld /var/www/
Output:
drwxr-xr-x 14 root root 4096 Jun 3 14:28 /var/www/
Make sure the document root is set to 775, which will allow groups write to this directory.
sudo chmod 775 /var/www/html
Make sure that your document root and all contents are owned by www-data.
sudo chown -R www-data:www-data /var/www/html*
Change all directories in the document root to 775. This will allow both the owner (www-data) and its group (which SFTP users belong to) to read, write and execute folders.
sudo find /var/www/html/ -type d -exec chmod 775 {} \;
Change all files in the document root to 664, this will allow both the owner and the group to read, write and execute files.
sudo find /var/www/html/ -type f -exec chmod 664 {} \;
Make sure that any new files or folders created by SFTP users inherit the www-data group.
sudo find /var/www/html -type d -exec chmod g+s {} \;
Now log into SFTP with you preferred FTP client and make sure you can create, edit and delete files and folders.
If you are not able to log in, check the auth log for the last 50 entries. Also try closing your FTP client and opening it again.
sudo tail -n 50 /var/log/auth.log
4.4. Adding More SFTP Users
If you need to provide other SFTP users write access to the document root, simply add their usernames separated by a comma, e.g. Match User webdev, webdev2, webdev3 in sshd_config (step 4.1) and then add the SFTP user to the www-data group (Step 4.2) .
5. Method Two: Better Security and SFTP User Management
In this method we will set up more restrictive permissions for your document root and use Linux user groups to manage SFTP users. This is the method I personally use for managing multiple virtual hosts, WordPress installs, and SFTP users on the one server.
Even if you are only hosting one website on your server, I strongly recommend this setup if you want the best security for your website’s document root.
This method removes www-data write access to the entire document root. Consider a scenario where a PHP script or WordPress plugin is hacked, the attacker could gain write access to your entire document root. To mitigate this, we need to only give www-data (and thus WordPress) write access to the directories where it only needs it to function properly.
If you haven’t installed your CMS yet, you should first carry out Method One, upload and install your CMS, then follow Method Two to lock down the CMS.
5.1. Create a New Linux User Group
With this method we will create a Linux User Group with the necessary access to the document root and then add our SFTP users to that group.
If you are hosting multiple websites on the one server with Apache or Nginx, you should name these groups so they correspond to your domain name. For example, sftp_example1_com and sftp_example2_org. This will make it a lot easier to keep track of your groups should they grow over time.
However, for the purposes of this guide, we will just call the group sftp_users and restrict this group to the default document root /var/www/html.
Add new group:
sudo groupadd sftp_users
5.2. Add SFTP User to Group
Add your SFTP user webdev (or whatever you called it) to the sftp_users group.
sudo usermod -a -G sftp_users webdev
Note: Groups do not take affect until the user logs out and in again. If you are already logged in as this user in your FTP client, close the program completely and then log in again.
5.3. Add Match Group Directive in SSH Config
In Method One we used the Match User directive, but by using the Match Group directive, you can manage multiple users and document roots far more effectively.
This allows you to restrict an entire group to a particular document root, and then you just add your SFTP users to that group with no additional configuration. This can save you a lot of time.
Begin by opening sshd_config
sudo nano /etc/ssh/sshd_config
Scroll down to the bottom of the SSH config file and add your new Match Group directive.
Make sure that ChrootDirectory is the directory above your document root. For example, if your document root is /var/www/html/, then the ChrootDirectory is /var/www/.
If you followed one of our previous guides on setting up multiple domains, your document root may be located in /var/www/mydomain.com/public_html, in that case, your ChrootDirectory would be /var/www/mydomain.com/.
Note: ForceCommand internal-sftp will force SFTP access only and not allow this SFTP user to log in via SSH.
/etc/ssh/sshd_config
Match Group sftp_users
ChrootDirectory /var/www/
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no
PasswordAuthentication yes
Save and exit (press CTRL + X, press Y and then press ENTER)
Test SSH config before restarting.
sudo sshd -t
If no errors, restart the sshd service for changes to take affect.
sudo service sshd restart
5.4. Set Directory Permissions
SFTP is very strict when it comes to chroot directory permissions and if they are not set correctly, you will not be able to log in, so please follow these instructions carefully.
The chroot is usually the directory above your document root. For example, by default /var/www/ is the chroot and /var/www/html is the document root. Another example, if your document root is one directory deeper such as /var/www/domain.com/public_html, then your chroot is /var/www/domain.com.
- The chroot directory *and all of its parents* must not have group or world write capabilities, otherwise SFTP log in will fail with fatal: bad ownership or modes for chroot directory component “/var/www/”. In other words, you must make sure both
/var/and/var/www/are set to755. (not775, which gives group write permissions). - The chroot directory *and all of its parents* must be owned by
root, otherwise SFTP log in will fail with fatal: bad ownership or modes for chroot directory component “/var/www/”. In other words, you must make sure both/var/and/var/www/are both owned byroot. - If your chroot directory is not
/var/wwwbut, for example,/var/www/domain.com, then you will need to apply these permissions androotownership to that folder as well and all of its parents!
Firstly, let’s check permissions and ownership for /var/ – they should be 755 and root by default.
sudo ls -ld /var/
Output:
drwxr-xr-x 14 root root 4096 Jul 30 02:24 /var/
If they do not match above, set permissions and ownership below.
sudo chmod 755 /var/
sudo chown root:root /var/
Now let’s apply the same permissions and ownership for your chroot. Assuming that your chroot is /var/www/, ensure that the directory is set to 755.
sudo chmod 755 /var/www/
Ensure your chroot directory is owned by root.
sudo chown root:root /var/www/
To check permissions for this directory:
sudo ls -ld /var/www/
Output:
drwxr-xr-x 14 root root 4096 Jun 3 14:28 /var/www/
Make sure the document root is set to 775, which will allow groups write to this directory.
sudo chmod 775 /var/www/html
Make sure that your document root and all contents are owned by root and the group sftp_users.
sudo chown -R root:sftp_users /var/www/html*
Change all directories in the document root to 775. This will allow the sftp_users group to read, write and execute folders.
sudo find /var/www/html/ -type d -exec chmod 775 {} \;
Change all files in the document root to 664, this will allow the sftp_users group to read, write and execute files.
sudo find /var/www/html/ -type f -exec chmod 664 {} \;
Make sure that any new files or folders created by the SFTP user inherit the group of the document root, in this example the sftp-users group.
sudo find /var/www/html -type d -exec chmod g+s {} \;
Now log into SFTP with you preferred FTP client and make sure you can create, edit and delete files and folders in the document root.
If you are not able to log in, check the auth log for the last 50 entries. Also try closing your FTP client and opening it again.
sudo tail -n 50 /var/log/auth.log
If you need to provide other SFTP users write access to the document root, simply add them to the sftp-users group (Step 5.2).
5.5. WordPress and www-data
www-data now has no write access to your document root, which is the preferred security setup. However, you may need to give www-data write access to certain files and directories in order for WordPress to function properly.
.htaccess and Apache
If you get an Apache error after setting permissions in the previous steps “You don’t have permission to access this resource. Server unable to read htaccess file, denying access to be safe”, you may need to give both www-data and the sftp-users group ownership of .htaccess.
sudo chown www-data:sftp_users /var/www/html/.htaccess
WordPress Uploads Directory
If your users need to upload files through the WordPress media library, you will need to give www-data write access to the uploads directory in /var/www/html/wp-content/uploads.
sudo chown -R www-data:sftp_users /var/www/html/wp-content/uploads*
This will give both WordPress and all your SFTP users write access to the uploads directory.
WordPress Cache Directory
If you are using a caching plugin such as W3 Total Cache plugin, you should give www-data write access to the cache directory in /var/www/html/wp-content/cache.
sudo chown -R www-data:sftp_users /var/www/html/wp-content/cache*
As well as the above, if you’re using W3 Total Cache, give www-data write access to the w3tc-config folder.
sudo chown -R www-data:sftp_users /var/www/html/wp-content/w3tc-config*
If installing W3 Total Cache for the first time, you may have to give www-data write access to wp-config.php and .htaccess, but you can revoke it later.
sudo chown www-data:sftp_users /var/www/html/wp-content/wp-config.php
sudo chown www-data:sftp_users /var/www/html/wp-content/.htaccess
WordFence
If you are using WordFence, you should give www-data write access to /wp-content/wflogs/.
sudo chown -R www-data:sftp_users /var/www/html/wp-content/wflogs*
If you are setting up WordFence Web Application Firewall (WAF), you will need to give www-data write access to .htaccess and the document root folder. You can revoke write access after WAF is configured.
WordPress Updates and Installing/Updating Plugins
WordPress normally uses www-data in order to update itself and add/update plugins. This is the most common setup but it is not the most secure because any rogue plugin could compromise your entire document root.
You should instead upload the SSH SFTP Updater Support plugin to your WordPress plugins directory and then activate it in WordPress.
Once activated, if you need to update WordPress or add/update plugins, you will be prompted for your SFTP username and password/SSH key. You can save this password or SSH key in your browser password manager so you don’t have to type it every time.
If the SSH SFTP Updater Support plugin isn’t prompting you to enter password when you try to update WordPress or alter plugins, add an entry in your wp-config.php file for define('FS_METHOD', 'ssh3');. Make sure there are no other entries for FS_METHOD in the config file.
Auto update WordPress plugins
WordPress 5.5 (released Aug 2020) now has the capability of automatically updating plugins itself. If you have 20+ WordPress installs to maintain like I do, this can make your life a lot easier! If you want this feature, you would have to give www-data write access to the plugins directory.
However, this introduces a new problem. If you have installed SSH SFTP Updater Support plugin, WordPress will not be able to update plugins itself despite having write access to the plugins folder. It will try to auto update the plugin but will be waiting for you to enter your SFTP username and password.
In this case, you should add define('FS_METHOD', 'direct'); in wp-config.php to force WordPress not to prompt for SFTP details and then it will auto update plugins itself. However, now you will not be able to update WordPress core in the control panel when an update is available. In this case you would have to temporarily comment out define('FS_METHOD', 'direct'); and then the WordPress core update will run. I haven’t found an easier method for this just yet, but as WordPress core updates aren’t as frequent as plugin updates, it’s not a big deal for me.
To allow WordPress to auto update plugins, give www-data write access to the wp-content and plugins directory.
sudo chown www-data:sftp_users /var/www/html/wp-content/
sudo chown -R www-data:sftp_users /var/www/html/wp-content/plugins*
You may also need to give www-data write access to the wp-content/upgrade directory if it exists.
sudo chown -R www-data:sftp_users /var/www/html/wp-content/upgrade*
If you already have plugins in the plugins folder, make sure to update all directories and files.
sudo find /var/www/html/wp-content/plugins -type d -exec chmod 775 {} \;
sudo find /var/www/html/wp-content/plugins -type f -exec chmod 664 {} \;
And make sure any new files and directories inherit the correct permissions.
sudo find /var/www/html/wp-content/plugins -type d -exec chmod g+s {} \;
And don’t forget to add define('FS_METHOD', 'direct'); to wp-config.php.
Just bear in mind that if there is a security breach, the attacker will have write access to your entire plugins folder, but not your entire document root.
But can WordPress core update itself?
This is one caveat of restricting where www-data can write to. If there is a critical security patch released, WordPress will not have the appropriate permissions to apply this patch on its own. You would have to give www-data write access to the document root and all WordPress folders, which sort of defeats the purpose of restricting permissions.
However, if you are serious about WordPress security, you should be proactively maintaining and updating your WordPress install frequently anyway. And in such eventuality where there is a critical security hole discovered in WordPress core, a hacker will still not be able to gain write access to your entire document root.
You can be notified of critical WordPress and plugin security patches via email using a plugin such as WordFence and then update WordPress yourself using the SSH SFTP Updater Support plugin as previously mentioned. This is the method that I personally employ for all my WordPress installs.
Let me know if this helped. Follow me on Twitter, Facebook and YouTube, or 🍊 buy me a smoothie.
p.s. I increased my AdSense revenue by 200% using AI 🤖. Read my Ezoic review to find out how.
https://fedingo.com/how-to-create-sftp-user-for-specific-directory/
How to Create SFTP User for Specific Directory
Here are the steps to create SFTP user for specific directory.
1. Edit SSH Config File
Open terminal and run the following command to edit SSH configuration file.
$ sudo vi /etc/ssh/sshd_config
Add the following lines at the bottom.
Match Group sftp
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
In the above line, we specify that users belonging to user group sftp should be restricted to their home directory (chroot). It is represented by %h in ChrootDirectory command.
2. Create SFTP User Group
Run the following commands to create SFTP user group. Replace username with your SFTP username.
$ groupadd sftp
$ usermod username -g sftp
$ usermod username -s /bin/false
$ usermod username -d /home/username
3. Restart SSH
Restart SSH server with the following commands. Replace username with your SFTP username.
$ sudo service ssh restart
4. Check Directory Permission (Optional)
If you are still experiencing problems, check the folder permissions with the following command.
$ sudo chmod 755 /home/username
That’s it. In this short article, we have seen how to restrict SFTP user to their home directory.
Also read:
This is the process:
Add the user to the group:
sudo usermod -aG www blubas in Whats the simplest way to edit and add files to "/var/www"?or just use
sudo adduser <username> www-dataInstall vsftpd
sudo apt-get install vsftpdConfigure vsftpd for remote access:
sudo nano /etc/vsftpd.confand inside the file setchroot_local_user=YESand ensure this is commented out:
#chroot_list_enable=YESas per documentation.
Restart nsftp:
sudo service vsftpd restartConfigure the user's home directory to the web directory (not in
/home):sudo usermod -d /var/www/mysite/ftpaccessdir <username>Configure ssh chroot
sudo nano /etc/ssh/sshd_configadd the following to the end:
Subsystem sftp internal-sftp Match user <username> ChrootDirectory /var/www/site ForceCommand internal-sftp AllowTcpForwarding noand ensure that further up in the file that this is commented out (ie before the one you just added)
#Subsystem sftp /usr/lib/openssh/sftp-serverRestart ssh
sudo service ssh restartChange the permissions for apache:
chown root:root /var/www chown root:root /var/www/site chmod 755 /var/wwwAs in the docs here.
Ensure that your directory has www-data access
sudo chown -R www-data:www-data /var/www/site chmod 755 /var/www/site