WordPress allows automated updates of plugins and the program itself, but it requires FTP or FTPS on the server. I did not want to add an FTP server to my host, and didn’t want to be sending my id/password to my shell account over the net in clear text either.
But then I found out through a few web pages that one can add SSH access to PHP on the server and use that.
All seemed straight forward except my host has password logins via SSH disabled. Must use a private/public key. I tried to carefully follow the instructions in each of the pages above and kept hitting failures.
So this blog entry is to rehash how to do this using private/public keys and how to work around an apparent bug in WordPress 2.7.1 with specifics for Centos 5.
- Installed ssh2. Since I have rpmforge set up as a yum repository I just had to yum install libssh2 and libssh2-devel
- To get ssh2 support added to PHP I had to add a few more packages: php-size and php-devel
- I then installed ssh2 via the command : pecl install -f ssh2
- Edited /etc/php.ini and added “extension=ssh2.so” to the Dynamic Extensions section.
- Restarted apache
OK, so far this matches up with the blog entries above (which have far more detail on the steps).
Then came the confusion. I had to create a special ssh2 private and public key because I didn’t want to use the one I use to log on to my shell. I used ssh-keygen to generate a pair with an esoteric name and no passphrase.
The key files need to be stored somewhere where the web server process can get to them. But you absolutely do not want someone being able to download your private key from the webserver, else they can use it to log into your shell via ssh since it has no pass phrase. So stash it somewhere outside the normal DocumentRoot for your web server. Some suggest stashing it in your own home directory and chmod it open. That’s not the best idea either.
The other consideration is the web server needs to log into a user account via ssh that has r/w access to all files that need to update. So whatever user owns all your wordpress files (which probably should NOT be the webserver username) is the one who will be used to log on for automatic updates.
So the final step is to append the contents of the ssh .pub file to the ~/.ssh/authorized_keys file of the owner of the wordpress files.
Now comes the bug which drove me nuts. The password does not work. Hence why I had to create a key without one. But leaving the password field blank does not work either. You have to enter something into that field. Anything. Then it should work.
Finally, if you don’t want to fill in the key locations, username, host, etc, everytime you do an update, you can define the values in wp-config.php file. Example:
define('FTP_BASE', '/var/www/wp/'); define('FTP_CONTENT_DIR', '/var/www/wp/wp-content/'); define('FTP_PLUGIN_DIR ', '/var/www/wp/wp-content/plugins/'); define('FTP_PUBKEY', '/var/www/.secret/id--wp.pub'); define('FTP_PRIKEY', '/var/www/.secret/id--wp'); define('FTP_USER', 'username'); define('FTP_PASS', 'foobar'); define('FTP_HOST', 'example.org:22');
The CODEX page has the private key define wrong as FTP_PRIVKEY when it should be FTP_PRIKEY — which also tripped me up.
Additional Security Steps
If the private key is obtained your wordpress account is compromised. Ensure that the file can’t be downloaded from the web server. You can also delete the public key from the authorized_keys file and only append it when you’re going to do automated site maintenance. That minimizes the window of time the private key could work even if it was obtained.