TerraFrost

Assuming that the output didn’t change when you did that… open class-wp-filesystem-ssh2.php and find this line:

if ( ! $this->link ) {
			$this->errors->add('connect', sprintf(__('Failed to connect to SSH2 Server %1$s:%2$s'), $this->options['hostname'], $this->options['port']));
			return false;
		}

Replace it with this:

if ( ! $this->link ) {
			$this->errors->add('connect', sprintf(__('Failed to connect to SSH2 Server %1$s:%2$s'), $this->options['hostname'], $this->options['port']));
                        exit('THIS FAR')
			return false;
		}

And tell me what happens.

I’m still getting the same error message.

The change I had you made wasn’t intended to fix the issue so much as to provide me info with which to diagnose it.

I’m not positive I understand your question, but if you are asking if when I delete a file via SFTP with a tool like FileZilla am I prompted to login, I suppose the answer is yes, once, then I am able to delete anything I want until I close the connection.

I mean like with other built-in WordPress methods. Like if you try to install a plugin via FTP, if you can, I imagine it’d behave similarly.

What I don’t understand is why the plugin (since it has clearly saved all my SSH info) is showing me the screen to enter all my info again when I perform an action that uses the plugin (like deleting a theme). It seems like it’s just confirming my info every time, which is unnecessary.

That’s probably your browser that’s saving the info – not the plugin. The plugin doesn’t save your info anywhere since doing so could constitute a vulnerability. ie. what if WordPress had an SQL injection vulnerability. Just SQL inject a SELECT and you get the SFTP credentials from the DB and then that SQL injection is the least of your concerns.

I apologize for the tardyness of this response.

Anyway…

In class-wp-filesystem-ssh2.php can you find and uncomment out this line?:

//define(‘NET_SFTP_LOGGING’, NET_SFTP_LOG_REALTIME);

If you could post the output after that that’d be helpful.

In lieu of those… it’s possible the server is just blocking requests from localhost or something. If that’s what was going on the logs wouldn’t be of too much use but the logs could provide insight if there was something else at play.

Thanks!

Sorry for the delay.

Anyway I suspect the problem is that the Apache root and the SSH server root are different. If you could confirm by running this script and telling me what the output is that’d be great:

<?php
include('Net/SFTP.php'); 

$sftp = new Net_SFTP('www.domain.tld');
if (!$sftp->login('username', 'password')) {
    exit('Login Failed');
} 

echo dirname(__FILE__) . '<br />';
echo $sftp->pwd();

Thanks!

Thanks for the fast and knowledgable response, what format do you need the SSH key for your plugin to be? OpenSSH, Bitvise, SSH2/other?

Pretty much any of these formats:

http://pastebin.com/t4TMDGuW

Those are the most commonly utilized key formats. If you’re using a key in another format let me know and I can consider adding support for it.

As for the log messages… could you change define('NET_SFTP_LOGGING', NET_SFTP_LOG_REALTIME); to //define('NET_SSH2_LOGGING', NET_SSH2_LOG_REALTIME); and tell me what you get?

Thanks!

I’m wondering why your plugin (which seems to be rated or reviewed as the only/or best SFTP utility) requires the server private keys vs public key.

That’s just how SSH public key auth works.

So let’s say you have an SSH server and an SSH client. You generate the public / private keypair and put the public key in the SSH server’s authorized_keys file.

To login the client first sends the public key corresponding to the private key to the server. The server either says yay or nay in response to that. If the server says yay then the session id is then signed by the private key and sent to the server. The server verifies the signature with the public key it has on file and lets you in if it succeeds in verification.

So the SSH client absolutely needs the private key. That’s just how SSH works.

The reason SSH was designed this way is so that the server doesn’t ever have to see the private key. If you just used the public key and didn’t do any signing with the private key it’d be analogous to a poorly protected password. ie. at least passwords are in theory shadowed / hashed / salted / whatever. authorized_keys aren’t.

If a malicious server were setup or the server compromised password auth would result in your password being compromised when you send it. With public key auth the private key is not compromised when you send the public key (and the public key is all you send anyway).

Now, in the case of this plugin, the SSH client and SSH server are on the same machine. There’s not much that can be done about that so long as you want WordPress to be able to update itself. To accommodate that the plugin doesn’t save the key to the filesystem or require the key live on the filesystem.

I suppose that’s not a perfect approach but a perfect approach would be… difficult.

Host key verification could be utilized. Maybe the host key could be stored in the SQL DB and checked every time you try to connect but an attacker could just update the DB.

And maybe the signature could be generated via the browser with JS instead of by the WordPress plugin but that presents it’s own problems as the session id is unique per SSH session. You create an SSH session, get the session ID and then to give the session ID to the browser you’d have to pretty much end the SSH session. Then when you reconnect to send the signed session id it won’t work because the session id of the new session will be different.

So if we were to establish a hierarchy of secure approaches it’d look something like this (weakest to strongest):

FTP
SFTP + auto updating wordpress
SFTP
nothing

Of course, this hierarchy doesn’t take into consideration the fact that an out-of-date wordpress is a security issue unto itself and hard-to-update WordPress’s will likely just not get updated.