huuanito

I’ve found that, if you store your creds in wp-config.php, once you use the plugin the first time to update software the next time it does not even take you to the creds page, it just goes ahead and uses your creds and starts downloading so there’s no need to set the default as SSH2 as it uses that automatically.

you can change the port by putting it after the servername in your logon creds like so for port 1234:

yourservername:1234

@wkdwich I just spent many hours debugging a similar issue, also with a non-standard port, with this really excellent plugin (thanks TerraFrost). I was getting connection refused over and over. Turned out it was a config issue with SSH due to multiple aliases onto the box in question for some odd reason SSH would only recognize the primary name and not the aliases. I could SSH from external but not localhost even with the firewall completely open.I had to add a
ListenAddress 127.0.0.1
to sshd_config and then it just worked.
I used some code from TerraFrost that I found in another thread to first confirm connection:
<?php
include(‘Net/SFTP.php’);

$sftp = new Net_SFTP(‘as.ucsd.edu’,7345);
if (!$sftp->login(‘aswebmaster’, ‘tAswsPhbC!’)) {
exit(‘Login Failed’);
}

echo dirname(__FILE__) . ‘
‘;
echo $sftp->pwd();
?>
then I hacked SFTP.php to find where it was balking.
Then I found this useful script to check connections via localhost:
<?php
function connect($host) {
$faultcode = null;
$faultstring = null;
$port = 1234;
$timeout = 10;
$conn = fsockopen($host, $port, $faultcode, $faultstring, $timeout);
if (!$conn) {
echo ‘faultcode=’ .$faultcode .’, faultstring=’ .$faultstring
.”\n”;
} else {
echo “Connected to $host OK\n”;
} // if
return $conn;
} // function

$result = connect(‘localhost’);
echo “
“;
$result = connect(‘127.0.0.1’);
echo “
“;
$result = connect(‘yoursite.tld’);
echo “
“;
$result = connect(‘www.someknownsite.com’);
?>

Hope this might help you debug your issue.

@marcelbrown
I had the exact same issue and it took many many hours to debug but I finally found it.

First this is how I debugged it:
* tried allowing the feed URL through our firewall which blocks outgoing http to reduce cross-site scripting attacks; didn’t work so I tried opening up the whole firewall, that didn’t work either;
* next there were a bunch of disabled functions so I enabled them all, that didn’t fix it either;
* next I figured it must be a PHP module that wasn’t loaded so I put a fresh install of WordPress on my personal website and tried the RSS widget and it just worked as expected using the same RSS URL;
To further refine that I painstakingly compared what was enabled in PHP on my personal server versus what was enabled on the non-working server and found a list of things that I thought might have something to do with it. Found that the non-working server did not have these likely candidates enabled (YMMV):
bzip2 curl curlwrappers hash libedit readline xmlreader zip

Enabled all those and it worked (woohoo!)

Next back-tracked to see which one it was. Thought curl was a likely culprit so took those 2 out and re-compiled PHP: RSS widget still worked. On a hunch took out xmlreader again and that was the one, well at least it is required as the RSS widget stopped working.
I stopped back-tracking there, not taking out the others but leaving in xmlreader as none of the remaining additions represented any security threats to my knowledge but I left curl disabled.

So in my case it seems to have been that xmlreader was not compiled into PHP (YMMV)

To summarize troubleshooting of this:

• test firewall issues
• test disabled PHP functions
• test missing PHP extensions