Creating additional SFTP users with access to specific sites?

Question

Has anyone sorted out a way to allow additional user accounts that have SFTP access only to specific sites/folders within a server?

I can add the additional accounts. I can add passwords and set up SFTP access. What I can't figure out is how to assign permissions to the site directory in a way that (1) allows a user to have a specific folder set up as their SFTP root while (2) also allowing WordPress access to write to the uploads folder.

In short, I got as far as locking everything down properly from the SFTP side, but that seemed to prevent WordPress from accepting file uploads since the folders were owned by a different user.

To anyone who's sorted this out - if you don't have time to share details about how to set this up properly, I'd at least settle for knowing that it's technically possible. I'm unsure if the fact that the various server processes run as www-data user totally precludes us from managing files via SFTP in this manner or if I've just yet to stumble across the proper file ownership configuration to make it all work.

BTW QROkes I've seen several places where this topic has been brought up and I understand you don't support it any official capacity, so please understand I'm not asking for that at all. I'm not interested in this from the strict security standpoint others have mentioned (i.e. a hack taking down all the sites on the server), I'm more interested in this from a practical/usability standpoint (I want to be able to give certain team members access to a site without fear that they'll accidentally goof up something across other sites)

Thanks all!

Answer 1

Hi,

if you want your uploads folder to be accessible both by user and www-data, you should 

1. chown it (recursive) to www-data:usergroup (the user should be a member of that group - typically a group with the same name as the user is automatically created when you create a user on debian based systems)
2. chmod your uploads folder recursively like this: chmod -R g+Xw uploads (allow group to list directories and write - the X is execute directories only)

As recommendation I would suggest to disable php in the uploads folder in your nginx/apache if not already done.

Hope this helps, 

regards, Greg

Comments

I will just write here my usecase where Webinoly is perfectly safe and has enough isolation. I provide people with managed Wordpress sites. My promise is: I take care of the code, you take care of the content.

I manage all the plugins and cores with wp-cli and I take advantage of the possibility of writing scripts, to help me with that. I as a unix user am the owner of all of the code, so www-data can't write to any of the folders except for the ones where php is disabled (Uploads and certain languages folders).

This makes my stack pretty safe but it also disables the possibility to install/update themes/plugins/core from the wp-admin section, which is ok with me, since my clients only want to control the content, while I use wp-cli for that.

For this matter Easyengine before, and now Webinoly is the perfect tool (with the exception of one patch I have to make). The official Easyengine 3 fork called WordOps has several downsides compared to Webinoly: the development is less dynamic, it still has some caveats easyengine was struggling with and, crucial for me, it is written in python. It would only make sense to me, that a script intended to manage php sites would be written either in php or in bash. I don't particularly love bash, but it has an upside of being easy to understand.

The one upside of WordOps is a bigger company and team behind it, making its development more stable in the long term. Webinoly has bus factor = 1, meaning if QROkes gets hit by a bus, we are all screwed. However, since the code is pretty well organised and neat (kudos to QROkes for that!), forking and maintaining it wouldn't be as much of a problem.

This is why Webinoly is usefull, secure and makes sense to me. It all depends on the usecase, how you work and what you want.

---

Thanks fellas, I appreciate the dialog and insights :D

---

BTW, WordOps doesn't support site isolation either, but I see that it's on their roadmap: https://github.com/WordOps/WordOps/issues/41

---

I don't know how WordOps will do the isolation thing, but all the solutions I have seen are using a third-party module for Nginx Purge Cache (needed when multiple users).

I just want to say "BE CAREFUL", this package is a feature natively included in NGINX Plus (not-free) and there are a couple of Open Source modules you can find in GitHub that are completely outdated, both of them are not actively maintained.

All the solutions I have seen are using one of these modules, compiling their own NGINX package. My thoughts:

• It's completely insane if you include outdated third-party modules to your server for security reasons.
• It's completely unethical if you are "hacking" Nginx just because you don't want to pay for the "Plus" version.

Just as a reference:

The most used modules are FRiCKLE and the Torden Fork.

Here is a better explanation: https://webinoly.com/en/faq/#2a3mfR

---

I have no idea how they will implement it either. They too admit that " it will probably be the biggest change on WO structure and configuration". In fact, I see that they moved it from the "In progress" list back to "To-do", so I wouldn't be surprised if they bumped into the same problems that you mention.

Answer 2

Try this method:
https://yungke.me/easyengine-chroot-sftp/

Original reference from EasyEngine:
https://easyengine.io/docs/chroot-sftp-easyengine/