TerraFrost
Forum Replies Created
-
Sounds like it’s not a problem with this plugin so much as it’s a problem with your (S)FTP client..
Would you be willing to send me (terrafrost@php.net) an email with your hostname, username and password (or private key) and I can upload the files myself?
Thanks!
Does it give you a line number?
Anyway maybe try doing this zip instead:
http://phpseclib.sourceforge.net/wordpress-svn.zip
I’m not going to make a new official release unless I’m sure the feature is working for people.
v0.3 is the old code. To get the latest you’d need to update your plugin to the latest SVN version. If you don’t know how to use SVN (or don’t have it installed or whatever) you can replace the contents of your sftp.php with this:
http://plugins.svn.wordpress.org/ssh-sftp-updater-support/trunk/sftp.php
Here’s a script that’ll help me diagnose this:
<?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();What I’m thinking is that the SFTP server is chroot’d but Apache isn’t. So dirname() is returning something like /home/user/public_html/wordpress whereas $sftp->pwd() is returning something like /. If that’s the case one thing that could be done is to set up /home/user as a symlink to /.
You can find the updated code in the latest SVN.
I’ve updated the core phpseclib files that the plugin uses although I’m not sure if that’d help.
If the initial connection is naturally slow it’s naturally slow. Can’t imagine why using phpseclib directly as opposed to through the plugin would make a difference..
The latest SVN now uses HTML5’s localStorage to save the key if it’s been copy / pasted.
It’ll save it on a per browser basis so if you use another browser on another computer you’ll need to re copy / paste the key.
Thanks for the feedback and I apologize for the delay!
The latest SVN should fix this – thanks and sorry for the delayed response!
You change the port by appending it to the hostname. eg. instead of localhost:22 do localhost:2222 or whatever
I just tried to install it on a fresh WordPress 3.2.1 and was unable to reproduce the problem you described.
Can you post a screenshot? Also, the version of WordPress you’re using and whatever plugins you might have installed.
Thanks!
The revision:
http://plugins.trac.wordpress.org/changeset/443069
The relevant changes were in sftp.php. You can copy / paste it here:
http://plugins.trac.wordpress.org/browser/ssh-sftp-updater-support/trunk?rev=443069
Alternatively, just downloading the zip file and dumping its contents into the plugins directory would work.
Private keys can now be uploaded.
Hmmm. I’ve been thinking about making it so locally stored files can be uploaded instead of having to be copy / pasted but there’s not really going to be any way to make it remember where the private key was stored on subsequent uploads. That’s really more the domain of the browser and there’s not a whole lot WordPress can do about that.
NicoMorrison – that’s true, but if someone can read and write files on the server space they can probably create a PHP script to read the password in the SQL DB, which would render any encryption meaningless.
If they only had read access to the files on the server space it’d be tougher for them to get the password, but still… if you’re worried about people being able to read the unencrypted private key than storing the password to decrypt the private key on the server probably isn’t hte best idea. You could encrypt the password, too, I suppose, but then the key to decrypt the password would have to be stored in plaintext too. At some point, you’re either going to just have to enter in a password or you’re going to have to store something that would render the point of encrypting the private key moot.
NicoMorrison – I’m unable to duplicate the FTP problem. If you could give me access to your admin control panel so that I might test it out on your server that’d be very helpful.
As for your feature requests… the saving of the private key location should be do’able enough. As for remembering the private key pass phrase… seems to me that you’d be best off just removing password protection offline and uploading it. I mean, I suppose, in theory, having the key on the filesystem and the password for the key in the DB could provide slightly better protection than just having a non-password protected key but I dunno… it’s something that I think ought to be discouraged none-the-less.
You can remove the password protection by using puttygen.