Now that #602582: Change name and description in update.info to reflect update manager functionality is in, and we're contemplating using a FileTransfer object inside install.php to deal with the settings.php dilemma (see #418302-90: Copy default.settings.php to settings.php during install IFF webserver owns files (FTP on shared hosting)), it'd be really nice if we had a subclass of the SSH FileTransfer class that knew how to use an SSH public key instead of a password. So, if you're setup on a site with SSH access, and you already have your public key granted access in your account's ~/.ssh/authorized_keys file, you could just have a text area to paste your public key in and use that instead of a password.

In that case, we could even consider stashing that string in a variable in your DB so you wouldn't have to re-paste it each time you needed to authorize (e.g. while updating the site), since there's no harm in anyone getting a copy of your public key (the only harm is if they can access your private key or your authorized_keys file).

This would be especially nice as a more secure solution so long as #607008: Fix bugs in https support and force using https for authorize.php if available isn't solved (and that'll never be a universal solution, since not every site will be able to support https).

Comments

dww’s picture

Eeek, brainfart. Reading http://www.php.net/manual/en/function.ssh2-auth-pubkey-file.php reminds me that this isn't really going to work. The FileTransfer class runs on the webserver (obviously) whereas your private key lives on your local machine where you're browsing from. And, you need the private key while trying to authenticate with a given public key. So, this doesn't really help us, in fact, since we'd need to get your private key over to the webserver somewhere. That's probably worse than what we have now. I'm thinking this should probably be "won't fix" and we should just put the effort into #607008: Fix bugs in https support and force using https for authorize.php if available instead...

Paul Natsuo Kishimoto’s picture

Agreed, having the webserver (albeit different parts of it) in possession of both keys defeats the purpose of a public/private key system.

dww’s picture

Status: Active » Closed (won't fix)

Yup, this is a bad move.