Automatic WordPress Updates Using FTP/FTPS or SSH

Introduction

When working with WordPress in a more secure environment

where websites are not entirely world-writable,

you will notice upgrades request FTP or FTPS credentials

as the server itself does not typically have write access in properly-configured environments.

Entering these credentials for every upgrade can become quite tedious,

and WordPress has implemented some constants

you can define within wp-config.php to make upgrades automatic.

It should be noted here that you can also make upgrades automatic

by setting the file ownership of all files within the WordPress directory

to the same user/group under which the webserver is running.

THIS IS HORRIBLE SECURITY PRACTICE!

While storing your FTP credentials for a specific user can also be considered insecure in certain instances,

it can be a very safe method to automate WordPress updates under the proper conditions.

Some general considerations which can make stored credentials MUCH more secure include:

FTP:

1. Creating a separate user and restricting its access to only allow connections from localhost
2. Ensuring your FTP daemon is “chrooting” the user to their own directory only
3. Configuring your FTP daemon to listen only on localhost, thus preventing external connections
4. Using something more secure than FTP, such as SSH — Yes, we realize this one does not actually improve FTP security

SSH:

1. Creating a separate user (usually an alias with the same UID, different GID) and
restricting access to only localhost for this specific user in sshd_config with the AllowHosts option
2. Creating some advanced SSH configuration such as chrooted SFTP-only users
3. Using public key authentication, which can be further secured
by specifying a “from” address in the user’s authorized_keys file

There are several other ways one can make their FTP/FTPS or SSH setup more secure,
but they are far beyond the scope of this post and can vary greatly in their application
due to the hosting environment and several other factors.
We are going to assume you’re already working with a secure setup for the purposes of this guide.

WordPress Upgrade Constants

From the WordPress Codex, the following constants are available to define FTP and SSH credentials in wp-config.php:

FS_METHOD

This setting forces the filesystem (or connection) method, and you probably won’t need to adjust or define it.
It can be one of: “direct”, “ssh2″, “ftpext”, or “ftpsockets”.

WordPress will automatically determine the proper method using the following preferential order:
—(Primary Preference) “direct” causes the use of direct file I/O requests from within PHP,
but this requires the webserver to have write access to your WordPress installation, which is NOT recommended.
This setting will be chosen automatically when the permissions allow.
—(Secondary Preference) “ssh2″ allows forcing usage of the SSH2 PHP extension if installed (via PECL).
—(3rd Preference) “ftpext” allows forcing the usage of the FTP PHP extension (this is usually the default when you connect via FTP/FTPS).
—(4th Preference) “ftpsockets” utilizes the PHP sockets class for FTP access (far less common, but can resolve FTP connection issues in rare cases).

FTP_BASE is the full path to the “base” (absolute path) folder of your WordPress installation.

FTP_CONTENT_DIR is the full path to the wp-content folder of your WordPress installation.

FTP_PLUGIN_DIR is the full path to the plugins folder of your WordPress installation.

FTP_PUBKEY is the full path to your SSH public key.

FTP_PRIKEY is the full path to your SSH private key.

FTP_USER is either your FTP or SSH username, depending on which method you use.

FTP_PASS is the password for the username entered for FTP_USER. If you are using SSH public key authentication, this can be left blank.

FTP_HOST is the hostname[:port] combination for your SSH/FTP server.
The default FTP port is 21 and the default SSH port is 22.
You only need to specify the port if using a non-standard one.

FTP_SSL is only for FTPS connections, and should not be defined
unless you have already configured your FTP daemon to support TLS.
Note – SFTP is NOT the same thing, so make sure you do not confuse the two.

Here’s an example of the most common configuration options with sample values so you can see the proper method of defining them within wp-config.php:

define('FS_METHOD', 'ftpext');
define('FTP_BASE', '/path/to/wordpress/');
define('FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/');
define('FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/');
define('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub');
define('FTP_PRIKEY', '/home/username/.ssh/id_rsa');
define('FTP_USER', 'username');
define('FTP_PASS', 'password');
define('FTP_HOST', 'ftp.example.org');
define('FTP_SSL', false);

To configure FTP/FTPS, you simply define the necessary constants from the list above in wp-config.php.
A minimal configuration requires at least
FTP_BASE, FTP_USER, FTP_PASS and FTP_HOST (usually 127.0.0.1).
Enter these required constants, also adding FTP_SSL (true) if using FTPS,
then your next upgrades should be automatic,
and you should no longer be prompted to enter these details.

Enabling SSH support in WordPress Using the PECL SSH2 extension

Most users are not aware of this, but WordPress already supports SSH connections in addition to FTP/FTPS by simply enabling the SSH2 extension in PHP. Let’s begin by installing the SSH2 extension via PECL.

On RHEL/CentOS, you will need the php-devel, php-pear and libssh2/libssh2-devel packages and a working compiler/development libraries if you installed PHP via Yum (RPM-based installation):

# yum install php-devel php-pear gcc gcc-c++ make automake autoconf pcre-devel re2c libssh2 libssh2-devel

With the necessary prerequisites installed, you can now use the CLI tool ‘pecl’ to automagically install the extension for you:

# pecl install ssh2-0.12

The reason we need to define the version here is to avoid an error message about the extension being in “beta,” since there was never a release of this particular extension that was labeled as “stable.” Once the installation completes successfully, you’ll be presented with a success message that instructs you to enable the extension in php.ini. When using CentOS, each extension’s INI file is stored separately from the main php.ini for cleanliness and easy addition/removal of extensions. To update /etc/php.d/ssh2.ini, we will use the following command:

# echo "extension=ssh2.so" > /etc/php.d/ssh2.ini

Now, running ‘php -m’ should show the SSH2 extension in the list of extensions. If you see it there, you must now restart your PHP processor (we’ll assume it’s Apache):

# /etc/init.d/httpd restart

You now have the SSH2 extension installed and enabled. If you have not already entered any constants in wp-config.php, you can attempt an upgrade or plugin installation/deletion and you will now see a new radio button that says SSH, in addition to the FTP and FTPS choices you’ve always had. To complete this configuration, you can now just enter the same minimal options used above, possibly including the FS_METHOD constant (ssh2) to ensure only SSH connections are attempted. However, we assume you would rather use the most secure method you can, so let’s configure SSH with public key authentication.

We’ll start by generating a public/private keypair, which we will later define in wp-config.php:

# ssh-keygen -t rsa -b 4096

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /home/user1/wp_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user1/wp_rsa.
Your public key has been saved in /home/user1/wp_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx root@server1.example.com

The location of the keys should be somewhere outside of your webroot, so the user’s home directory is usually a safe choice. You should NOT enter a password here, as there have been many issues getting passworded SSH keys to work properly with WordPress. After creating the keypair, we need to make it readable by the webserver (we’ll assume your webserver runs under the “apache” user for simplicity):

# chown user1:apache /home/user1/wp_rsa
# chown user1:apache /home/user1/wp_rsa.pub
# chmod 0640 /home/user1/wp_rsa
# chmod 0640 /home/user1/wp_rsa.pub

Next, you just need to edit wp_rsa.pub to specify the ‘from=’ option and add the contents to the authorized_keys file in /home/user1/.ssh/authorized_keys:

# vim /home/user1/wp_rsa.pub

You can use whichever editor you please (vi, nano, emacs, etc), so there’s no need to cry. Once you’ve opened the file, add the following ‘from=’ restriction at the beginning of the line (there should only be one very long line) right before ssh-rsa and the key data:

from="127.0.0.1" ssh-rsa ...

Now, we can actually place the public key’s contents in the user’s authorized_keys file:

# mkdir /home/user1/.ssh
# chown user1:user1 /home/user1/.ssh/
# chmod 0700 /home/user1/.ssh/
# cat /home/user1/wp_rsa.pub >> /home/user1/.ssh/authorized_keys
# chown user1:user1 /home/user1/.ssh/authorized_keys
# chmod 0644 /home/user1/.ssh/authorized_keys

As long as PubkeyAuthentication is enabled in sshd_config (default), you should now be ready to configure wp-config.php for automatic SSH upgrades:

define('FTP_PUBKEY','/home/user1/wp_rsa.pub');
define('FTP_PRIKEY','/home/user1/wp_rsa');
define('FTP_USER','user1');
define('FTP_PASS','');
define('FTP_HOST','127.0.0.1:22');

From now on, installing/removing/upgrading WordPress and its plugins should no longer prompt you for credentials. Happy blogging!