我正在尝试在 Debian 8 系统上建立一个安全的 WordPress 网站，其要求如下：
- 自动核心更新（FS_method“direct”）
- chrooted SFTP 访问 /wp-content（针对单个用户）
我确信这是一个相当标准的设置。不过，我找不到如何将它们组合在一起的教程。
首先，为了使使用 FS_method“直接”的自动核心更新起作用，WordPress 的大部分内容必须归 www-data 所有，即：
chown -R www-data.www-data /var/www/wordpress
此外，我有一个本地帐户“sftp-wordpress”，我将其放入“www-data”组。
我把 wp-content 和组内的所有内容都设为可写（组是 www-data，见上文），这样 sftp-wordpress 就可以写入，而且 - 为了安全起见 - 我把“wp-content”及其子目录设置为 setgid：
chmod -R g+w /var/www/wordpress/wp-content
find /var/www/wordpress/wp-content -type d -exec chmod g+s {} \;
第一个问题：为了设置 chroot，我将以下内容放入 /etc/ssh/sshd_config 中：
Match User sftp_wordpress
ChrootDirectory /var/www/wordpress/wp-content
ForceCommand internal-sftp -u 0002
AllowTcpForwarding no
这不起作用，因为 OpenSSH 不喜欢 ChrootDirectory 的权限和所有者：
fatal: bad ownership or modes for chroot directory "/var/www/wordpress/wp-content"
因此，我通过禁用 ChrootDirectory 指令暂时取消了 chroot 要求。
此时，我可以将文件上传到 wp-content。文件将显示所有者“sftp-wordpress”（可能是问题用于 WordPress 更新？）和组“www-data”。
另一个问题上传的文件和目录不是可组写的，因此 Apache 进程无法修改它们。如果 WordPress 想要修改它们，这就有问题了。
“umask 0002”不会有帮助，因为（与这里的其他问题不同）它不会执行组写权限。
事实上，上传的文件在服务器上是可组写的，如果它们在客户端上是可组写的 - 这远非解决方案，因为你不能指望 SFTP 会在他们那边解决这个问题。
我想知道是否有针对此 WordPress 设置的一致解决方案。
答案1
为了让 openssh 接受它，chroot 目录需要由 root 拥有，这是出于安全目的。
进一步解释请参见：chroot 目录组件的所有权或模式不正确
Chroot目录
指定验证后 chroot(2) 到的目录的路径名。 路径名的所有组件都必须是根目录拥有的目录，并且任何其他用户或组都无法写入. chroot 之后，sshd(8) 将工作目录更改为用户的主目录。
我认为解决方案可能是将上传位置与 wordpress 可查看的位置分开。
您可以创建一种暂存区，用户可以通过 chrooted 位置的 openssh sftp 服务器上传文件。然后您的系统会有一个 cronjob，它会定期运行一个脚本，该脚本将检查上传位置并对上传的文件执行适当的操作。
它可以发送一封电子邮件请求人工干预，也可以进行一些自动文件检查、病毒扫描，无论你认为什么都行。然后将文件复制或移动到 wordpress 可以处理的位置。
我认为实际上没有一致的解决方案，因为许多情况都非常独特。但使用暂存区来存储上传的文件在许多情况下并不罕见。而且它增加了一定程度的安全性。
答案2
一个可能的答案似乎是这种设置确实是不可能的（没有对各种组件进行重新配置）。
另一种方法是放弃 FS_METHOD“direct”，转而采用“ssh”、“ftpext”或“ftpsocket”等替代方法。这样就不再需要网络服务器能够更改 WordPress 文件。相反，您可以告诉 WordPress 如何通过 FTP 或 SSH 访问和更改自己的文件。