The Set Up
For the purpose of this guide:
- PHP-FPM runs as an unprivileged user such as www-data or www (FreeBSD).
- The owner of the web files is non-root such as “WebUser” belonging to the www/www-data group.
- PECL-ssh2 has been installed for PHP
- You currently use paired key authentication (How-To)
The Guild
If you are like myself, you may be running your wordpress-driven site on a VPS without a control panel, or even without a typical FTP server (ie: SSH/SCP only). I’ll show you how to set up wordpress to update itself via SSH, while only doing so when you allow it.
For those of you using Apache’s SuExec, this guide will not be of much use, as SuExec executes PHP and other processes as the same user that owns the files. In which case the permission setting at the very bottom of this page may be of more help to you, or you can use ‘direct’ mode instead of ssh2.
PECL-ssh2
First thing we need to do is make sure PHP has the SSH2 extension installed. This can be installed via PECL, or in the case of FreeBSD ports:
cd /usr/ports/www/security/pecl-ssh2 make install clean service php-fpm restart
Once installed SSH2 will be visible on a php_info() output.
Paired Key Authentication for PHP
Now we need to provide PHP with a public/private key, for this purpose let us create a folder to store these files in. Because PHP runs as www, and the files are owned by WebUser (or whichever username you’ve given to manage your web files), PHP will not have free reign to any existing paired keys that user may already exist. Besides it is not advisable to use the same keys for your main Web User.
For my purposes, websites are stored in a path under the Web user’s home folder.
Example: /home/WebUser/www/domain_name.com/public_html
We can create a folder in “www” (outside of any of the website’s public documents), named .ssh:
mkdir /home/WebUser/www/.ssh cd /home/WebUser/www/.ssh ssh-keygen -b 4096 -C php-key -t rsa ** When asked use the path /home/WebUser/www/.ssh/id_rsa instead of the default ** Provide a passphrase, DO NOT leave it blank.
You do not need to create such a strong key using 4096 bits for local communication, nor do you need to store it in a folder named “.ssh”. The keys do not even need to be named id_rsa, so feel free to mix it up a bit, just remember your public key will have a pub extension. You can even create separate keys for each website so as long as you do not place them inside the publicly accessible root.
The “php-key” portion of the command is the comment, if you are using multiple keys, you can edit this comment to help keep organized.
Authorizing the new keys
As mentioned before, this guide assumes you are already using paired key authenication. As a result there should be an authorized_keys file placed in your User’s .ssh folder (typically /home/UserName/.ssh/authorized_keys).
In order for the new keys to be given permission to use the web user’s credentials, we need to add the content of id_rsa.pub to authorized_keys. You may do this either in an editor such as WinSCP, or via the command line, such as using the ‘cat’ command:
cat /home/WebUser/www/.ssh/id_rsa.pub >> /home/WebUser/.ssh/authorized_keys
Make sure there is a double arrow in the command above and not a single one, or you risk replacing the entire content of authorized_keys with just that one public key.
The purpose of the passphrase, which is not required but STRONGLY encouraged is to make it so that PHP cannot utilize this key unless you explicitly provide the passphrase. This would of course prevent a malicious script from acting as the main Web User, when you are not in the process of performing an update or installation (since your passphrase would only be provided at those times).
While you can also store the passphrase in the wp-config.php as the FTP_PASS, it is also strongly discouraged.
Setting Key Ownership and Permission
Because PHP in this configuration runs as www-data or www, it will not be able to access the newly created keys unless we change their ownership and permission. With the commands below we’re setting the ownership of the .ssh folder to www:www (or www-data:www-data) and changing the permissions so that only the owner of the file can read the private key, and owner+group can read the public key; Though only the owner really ever needs to see it, as the public key provided in the authorized_keys, but normally you will not be logged in as www, and may need to read the content of the file.
chown -R www:www /home/WebUser/www/.ssh chmod 0400 /home/WebUser/www/.ssh/id_rsa chmod 0440 /home/WebUser/www/.ssh/id_rsa.pub
Modifying wp-config.php
Below is the code segment that needs to be added to the wp-config.php file. First the method is defined as ssh2, then the absolute folder paths, then the paths to the public and private key, and finally the username and host SSH will attempt to connect to.
define('FS_METHOD', 'ssh2');
define('FTP_BASE', '/home/WebUser/www/YourDomain.com/public_html/WordPressRoot/');
define('FTP_CONTENT_DIR', '/home/WebUser/www/YourDomain.com/public_html/WordPressRoot/wp-content/');
define('FTP_PLUGIN_DIR ', '/home/WebUser/www/YourDomain.com/public_html/WordPressRoot/wp-content/plugins/');
define('FTP_PUBKEY', '/home/WebUser/www/.ssh/id_rsa.pub');
define('FTP_PRIKEY', '/home/WebUser/www/.ssh/id_rsa');
define('FTP_USER', 'WebUser');
define('FTP_HOST', 'YourDomain.com');
// If you are not using port 22, append :Port# to the domain, such as YourDomain:1212With the following in place, you’ll be able to:
- Install a Theme or Plugin from WordPress itself
- Update a Theme or Plugin automatically in WordPress
- Delete a Theme or Plugin from within WordPress
- Upgrade WordPress Itself from the automatic update utility
Each time you perform any of the above tasks, you’ll be informed that the public and private keys are invalid, this error is only shown because without the passphrase it cannot continue. So provide the passphrase via the password field each time to perform the tasks. Make sure the “ssh2” radio button has been selected when you do this.
If you are uploading a zip file to install a theme/plugin
While the setting above will work for the most part with the automatic fetch-n-install, such as searching for plugin and then clicking install. It may not work when providing a zip file from your local storage.
If this becomes the case we just need to adjust the permissions of the upload directory. Assuming your files are owned by WebUser:www and PHP runs as www:www, we need to set the permissions of the /wp-content/uploads folder to 775 (read/write/execute for both the WebUser owner, and www group, but keep read/execute on ‘other’).
chmod 0775 /home/WebUser/www/YourDomain.com/public_html/wp-content/uploads/
If you have content already in there you may need to add on the recursive flag with -R before 0775.
chmod -R 0775 /home/WebUser/www/YourDomain.com/public_html/wp-content/uploads/
For the purpose of installations, this is only required in order for PHP to move the uploaded zip file to the uploads folder where it will be unpacked. From there the familiar SSH dialog will appear to continue the rest of the installation. After which the uploaded zip file will be removed from the uploads folder.
Securing your Uploads folder on Nginx
Because PHP is now capable of writing to the uploads folder, there is a chance that someone may attempt to upload a script into it and as such execute from it. The uploads folder should not host any executable scripts so to fix this we need to add some rules into the configuration for Nginx.
This location block should go before the PHP location block.
location ~* ^/wp-content/uploads/.*\.php$ {
return 403;
}Any attempts to call a PHP script from the uploads folder will now be met with a forbidden response code.
For further information on securing PHP and Nginx please refer to Securing Nginx & PHP