The error the upgrade tool gives is “There was an error connecting to the server, Please verify the settings are correct.”

I’ve confirmed that my public key works from the command line by doing:

sudo su www-data
ssh -i /path/to/private/id_rsa user@host

(Although first I had to give www-data write permissions to /var/www/.ssh/known_hosts.)

If I run with FTP_PASS empty, I get the error from the upgrade page and nothing in /var/log/auth.log. If I run with a random FTP_PASS, I get “Did not receive identification string from 192.168.1.1″.

Version info:

Server version: Apache/2.2.14 (Debian)
Server built: Jan 2 2010 23:02:48
OpenSSH_5.3p1 Debian-1, OpenSSL 0.9.8k 25 Mar 2009

I have /etc/php5/conf.d/ssh2.ini set up as per your instructions.

While I don’t like the idea of consultants / experts demanding people point out how to fix it or shut up, I’ll take a stab at it.

1. Read http://wiki.hands.com//howto/passphraseless-ssh/ . Not all of it can be applied, but it’s good to start with best practices.
2. Determine the task that needs to be done; I gather the purpose is to transfer from wp-uploads to wp-content in situations where the web server is running with insufficient permissions.
3. Restrict the SSH key to ‘from=localhost.’
4. Perhaps write a local script to do this, and restrict the key to only that script with command=.
5. Perhaps change the group key to something relevant; debian uses www-data as a group for webserver users.

What does this mean? It means that anyone with access to your server, legitimate or otherwise, will now have access to login to the user which has access to your WordPress directory and your WordPress SQL Database username, password, and location.

What should I do? It almost seems like FTP could be more secure in this case, but if you really want to use SSH here are my recommendations:

First: USE A PASSPHRASE, and make it strong (1), this way anyone who finds your “private” key won’t instantly have access to your server.

Second: Don’t change the permissions of your .ssh folder, apache only needs access to these two files, put them somewhere else, but NOT IN A WEB DIRECTORY! The .ssh folder should be 700 and files 600 (2).

Third: Don’t keep id_rsa readable by everyone when it doesn’t need to be. If you need to upgrade wordpress change its permissions to 644, upgrade, and then change it back to 600.

Fourth: (security through obscurity) Don’t keep the file named id_rsa. If I were a hacker with unprivileged access to a wordpress server, after reading this article (and others like it), my first command would be:

find / -name id_rsa 2>/dev/null

Which would point me to any files named id_rsa on the server.

Rick, in the post below, mentions that CentOS’s Apache install won’t let itself view ~/.ssh/ and that’s because CentOS knows this is a horrible idea!

Instead of all of this, why not just setup an FTP daemon that only accepts traffic from localhost?

References:
1) http://www.utexas.edu/its/secure/articles/keep_safe_with_strong_passwords.php
2) http://www.linuxforums.org/articles/file-permissions_94.html

I’ll be writing a follow-up post soon about permissions and users, making it even easier to upgrade. Subscribe to my WordPress site where the post will be written.