3 ms·

I'd really like if WP offered an inbuilt way of doing installs/updates via ssh. defaults seem to require plaintext FTP credentials to itself. I know there wa

I'd really like if WP offered an inbuilt way of doing installs/updates via ssh. defaults seem to require plaintext FTP credentials to itself. I know there was an ssh plugin, and I know it couldn't be the only option (or perhaps even default), but having it as an available option on install would still be nice...

stephenr 9y ago
I’m not sure that really improves the situation much. It’d still have effective write permission to itself. On shared hosting I’d have thought a user-account cronjob calling the app via cli (not via curl) could do the updates - but wordpress has always veered for “offer a shit solution to everyone” over “offer a secure solution to some subset of everyone”.
- mgkimsal 9y ago
  by no means is it a big improvement, but it's forced me, on more than one occasion, to end up needing to enable an FTP server just to accommodate this behaviour. Just... more work (and increased insecurity, even if only for a small window of time). my default for wp installs is to just take write permission off everything all the time, then re-enable it when I know I will be doing something needing to write (updates, etc). There are likely some actual WP users who are not technical yet actually use the system to do their own content updates, but almost everyone I know who's using wordpress is managing it on behalf of their clients, doing all the content updates for them. These people could/should probably get familiar enough with ssh and stronger security practices, but the 'one click update' for themes/plugins/core seems to give a very strong (but ...problematic) sense of security.
jlgaddis 9y ago
You can always just grab a tarball, uncompress it locally, and then connect to the server with your favorite SFTP client to upload the new files to the server. It's not exactly elegant but it is possible. I did that more than once back in the good ol' days before the fancy schmancy automatic updates. After you do it a few times, though, you'll probably just give up and modify the file permissions so that WordPress can update itself at which point... If the user that WordPress (or the web server stack, I suppose) is running as has write permissions on the directory where WordPress lives, it can update itself directly without having to FTP to localhost or whatever. Of course, typically we'd say it would be a bad idea for the application to be able to do that but blah blah risk assessment blah blah trade-offs blah blah ... For a long while, this was a widely accepted/standard way of hosting multiple customers on a shared web server, using something like suexec+php-cgi or (even better, IMO) mpm-itk. Then, each customer's WordPress site would run under its own uid/gid in order to isolate them from one another. A single customer could break their own instance or allow it to get hacked over and over again, but at least it couldn't get to other users' sites. I'm not sure how the large shared web hosts are handling this nowadays or if anything has even changed. (Edit: After reading your other comments, mgkimsal, it's obvious that you already know all of this but I'm not going to delete/edit my comment now.)
- mgkimsal 9y ago
  no worries - thanks. I'm sometimes deeply aware and involved in it, then move on to other areas, and don't have to think about it for a while. the apparent moves to nginx/fpm in the php as a 'default' for many situations has, I admit, perplexed me a bit - my muscle memory has not adapted to newer ways of dealing with this approach. So many of the problems in WP stem from the extreme 'hackability' from the early days, and a resistance to push for more security by default (the lack of ability to even attempt to install updates via ssh is, imo, a good example).
pmlnr 9y ago
http://wp-cli.org/ http://wp-cli.org/
- stephenr 9y ago
  Right, and if Wordpress cared about security, they'd force it's use for updates, via elevated permissions.

stephenr 9y ago

I’m not sure that really improves the situation much. It’d still have effective write permission to itself. On shared hosting I’d have thought a user-account cronjob calling the app via cli (not via curl) could do the updates - but wordpress has always veered for “offer a shit solution to everyone” over “offer a secure solution to some subset of everyone”.

mgkimsal 9y ago
by no means is it a big improvement, but it's forced me, on more than one occasion, to end up needing to enable an FTP server just to accommodate this behaviour. Just... more work (and increased insecurity, even if only for a small window of time). my default for wp installs is to just take write permission off everything all the time, then re-enable it when I know I will be doing something needing to write (updates, etc). There are likely some actual WP users who are not technical yet actually use the system to do their own content updates, but almost everyone I know who's using wordpress is managing it on behalf of their clients, doing all the content updates for them. These people could/should probably get familiar enough with ssh and stronger security practices, but the 'one click update' for themes/plugins/core seems to give a very strong (but ...problematic) sense of security.

jlgaddis 9y ago

You can always just grab a tarball, uncompress it locally, and then connect to the server with your favorite SFTP client to upload the new files to the server. It's not exactly elegant but it is possible. I did that more than once back in the good ol' days before the fancy schmancy automatic updates. After you do it a few times, though, you'll probably just give up and modify the file permissions so that WordPress can update itself at which point... If the user that WordPress (or the web server stack, I suppose) is running as has write permissions on the directory where WordPress lives, it can update itself directly without having to FTP to localhost or whatever. Of course, typically we'd say it would be a bad idea for the application to be able to do that but blah blah risk assessment blah blah trade-offs blah blah ... For a long while, this was a widely accepted/standard way of hosting multiple customers on a shared web server, using something like suexec+php-cgi or (even better, IMO) mpm-itk. Then, each customer's WordPress site would run under its own uid/gid in order to isolate them from one another. A single customer could break their own instance or allow it to get hacked over and over again, but at least it couldn't get to other users' sites. I'm not sure how the large shared web hosts are handling this nowadays or if anything has even changed. (Edit: After reading your other comments, mgkimsal, it's obvious that you already know all of this but I'm not going to delete/edit my comment now.)

mgkimsal 9y ago
no worries - thanks. I'm sometimes deeply aware and involved in it, then move on to other areas, and don't have to think about it for a while. the apparent moves to nginx/fpm in the php as a 'default' for many situations has, I admit, perplexed me a bit - my muscle memory has not adapted to newer ways of dealing with this approach. So many of the problems in WP stem from the extreme 'hackability' from the early days, and a resistance to push for more security by default (the lack of ability to even attempt to install updates via ssh is, imo, a good example).

pmlnr 9y ago

http://wp-cli.org/ http://wp-cli.org/

stephenr 9y ago
Right, and if Wordpress cared about security, they'd force it's use for updates, via elevated permissions.