I discovered that WordPress has built-in support for updating via SSH2 if PHP has the PECL SSH2 library installed. Following is a quick summary of how to get it running.

The PECL ssh2 library requires libssh2 which I downloaded and then compiled painlessly with a

$ ./configure
$ make
$ make install

Once libssh2 was compiled and installed, I installed the PECL ssh2 library via

$ pecl install -f ssh2

The -f flag is to force the install since ssh2 is still in beta & you’d otherwise get a warning like

Failed to download pecl/ssh2 within preferred state "stable", latest release is version 0.11.0, stability "beta", use "channel://pecl.php.net/ssh2-0.11.0" to install

After installing ssh2 via pecl, i edited the php.ini file (located at /etc/php.ini for me) to tell PHP to load this extension

extension=ssh2.so

and then restart apache afterwards (via apachctl, service httpd restart, or whatever is appropriate for your system) so that the library would be available to PHP.

After apache comes back up, you should see a new option (SSH) in the wordpress upgrade page (which applies to plugins as well).

BTW, if you’re on a Red Hat Fedora system and/or use yum, you might be able to just pull the libssh2 rpm from yum instead of compiling it:

$ yum install libssh2
$ yum install libssh2-devel
$ yum install libssh2-docs

I'm sorry to have to inform you that your message could
not be delivered to one or more recipients. It's
attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<example@example.com>: cannot update mailbox
/var/mail/example for user example. error writing message:
File too large

Ends up that Postfix has a mailbox_size_limit setting & since I didn’t have that set, it was set to the default 50MB. The user’s mailbox was near that limit so I up’d the default to 150MB in /etc/postfix/main.cf:

mailbox_size_limit = 157286400

then reloaded postfix:

service postfix reload

and all was good again.

smtpd_sender_restrictions = reject_unknown_address

smtpd_client_restrictions =
        reject_invalid_hostname,
        reject_non_fqdn_hostname,
        reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        permit_mynetworks,
        reject_unauth_destination,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client dnsbl-1.uceprotect.net,
        permit

message_size_limit = 15728639
disable_vrfy_command = yes
smtpd_helo_required = yes

Note that I’m using 3 DNSBLs (spamhaus, spamcop, and uceprotect — the values for reject_rbl_client) and they are placed towards the end of smtpd_client_restrictions. I only want the external DNSBL DNS lookups to occur if the mail passes the simpler checks first.

Seems to be doing a decent job. I still get a few pieces of spam that fall through the cracks, but don’t want it so aggressive that letgitimate email doesn’t get to me. Here’s the summary data from logwatch from yesterday:

        1   Reject relay denied                        0.02%
      207   Reject HELO/EHLO                           4.40%
      442   Reject unknown user                        9.40%
     4053   Reject RBL                                86.18%
 --------   ------------------------------------------------
     4703   Total Rejects                            100.00%

The DNSBLs combined rejected over 4000 pieces of mail, most of which would have likely been caught by spamassassin anyways if I didn’t have the DNSBL checks, but it’s nice that they didn’t get past my mail server and into my mailbox!