2

I was able to upgrade Wordpress 4.0 on my local machine, and I also just updated some plugins on the production machine, but when I try to update Wordpress 4.0 on the production machine, it is asking for my FTP credentials. Why is it asking for these when it never needed them before?

Could CloudFlare have anything to do with it?

I found this http://codex.wordpress.org/Dashboard_Updates_Screen#Troubleshooting

I tried to use chown -R apache:apache * on the Wordpress install, but it still asks for FTP credentials. I don't want to set up the FTP server. Why would it need the FTP server when it is doing the fetching?

5 Answers 5

4

I had to also change the owner of the root web directory.

chown apache:apache .   # or chown apache:apache /var/www/html

Edit by Otto: Chloe, as you asked for more information than I could reasonably put into a comment, I'm appending this on to your answer. I hope that is okay. If not, feel free to revert it, or let me know and I will do so.

The reason that I commented about this being a security issue has to do with file ownership and restricting permissions and limiting access.

Unix like systems contain the concept of "owners" and "permissions". Files are owned by some user account, and have permissions that control whether they are read, write, or executable by other accounts. This is inherently a security feature, to prevent other accounts from being able to write to your files, or perhaps to allow them to do so.

Running programs also have "owners". Those programs inherit the permission capabilities of their owner. If you run a program, it can do anything you can do, but will be prevented from doing anything that you can not, because it is "owned" by your user account.

When it comes to web servers, you're essentially allowing the outside world to run a program on your computer. Because of this, ownership is important, and so most web servers run as a "www" user, or in the common case of the Apache web server, as the "apache" user.

If somebody is able to hack their way in through some program running on your website, then they will gain control over that program, but will still be limited by the capabilities of that program. If they hack a process run by "apache", then their user will be "apache" and they will only have access as the "apache" user account.

Thus, having your files owned by "apache" is a security issue, because you're essentially saying that anybody in the world is the owner of these files. Anybody who happens to get in through that door can see them, edit them, modify them.

On the other hand, if the user account that owned the files was "user" and "apache" just happened to have permission to read the files, but not write to them, then the web server could still get its job done. It could read the files, run the PHP scripts, do all the stuff it is supposed to do... but not modify the files.

This is why WordPress asks for FTP credentials. When it is self-updating, it notices that the WP files are owned by "user" but WordPress is actually running as "apache". Thus, it can't properly update without changing the owner. The "apache" user cannot write files owned by "user". It doesn't have this permission. More to the point, WordPress needs to create new files and delete old ones as well. So if it does that while running as "apache", then the new files will be owned by "apache", when they should be owned by "user". It intentionally stops the update at that point because it cannot create files with the correct ownership.

Asking for FTP gives it a second approach. It can connect back to its own server via FTP, and using those credentials, it can write files as the correct user... For that one time only. After it disconnects, the credentials are forgotten. Safe all around.

In other words, when you put in FTP information, you are giving WordPress security credentials to be able to change the files that one time. By making the files owned by "apache" instead, you are giving WordPress the ability to change the files all the time, without any additional credentials. You have bypassed the security feature here, where as before, WordPress could not change the files without your login information, now it can. That's a problem.

Now, maybe you don't run the FTP service normally. Maybe you only use SSH. That's okay too. In that case, look into adding the PHP SSH2 extension to your server's PHP configuration. If WordPress finds that, instead of just FTP, you will also have the option for SFTP, which uses the SSH connection to authenticate and copy the files instead. Same principles apply, it's trying to write files with the correct ownership for them to prevent security issues.

Security isn't a binary thing, it has layers. If somebody gets unauthorized access, having things configured correctly can help to limit the amount of possible damage they can do. File and process ownership is a pretty low level bit of security in unix-type systems, but it's still an important one.

5
  • 1
    This is a bad idea, and a potential security issue. Asking for FTP credentials is a security feature, you should not attempt to work around it like this.
    – Otto
    Sep 22, 2014 at 18:46
  • Can you explain how it is a security issue? Can you explain how giving out login FTP credentials or even adding another running service is a security feature, and not an issue?
    – Chloe
    Sep 27, 2014 at 20:03
  • 1
    Since I can't fit a response to that in a comment, I edited your answer instead to include my response.
    – Otto
    Sep 28, 2014 at 1:04
  • I guess I don't trust giving out the root password. WordPress needs write permissions anyways for uploading and deleting image files and cache files on various subdirectories. Ideally everything would be owned by root, but it wouldn't function then. I saw little harm granting write permissions to the root web directory, as it's the only thing running on the machine.
    – Chloe
    Oct 1, 2014 at 19:34
  • 1
    Having the ability to write image files is slightly different than writing PHP code, from a security standpoint. Nevertheless, I would suggest setting up the SSH2 extension for PHP and creating a special keypair just for it to use instead. Then you can eliminate that process and still be secure.
    – Otto
    Oct 1, 2014 at 20:15
1

Try the following steps and it will probably allow you to update everything.

  1. Open wp-config.php and add `

define('FS_METHOD','direct');

  1. The last step is to change the owner:group of the directory which you already did. Quick note, if you are using apache2, the group is www-data and not apache. So it would be like this

sudo chown -R <user>:www-data <WordPress-directory>

Hope it works.

6
  • NEVER set the permissions to 777, just to make it very clear I repeat - NEVER. Sep 20, 2014 at 22:34
  • I just told him to retrieve the permissions afterwards. It just for the update. Let me know if there are any scenarios that in this period of time there would be a security issue.
    – negletios
    Sep 20, 2014 at 22:37
  • There are plenty, besides it's just never necessary. Sep 20, 2014 at 22:39
  • OK. I will update the answer, removing the first step. Only with FS_METHOD will probably work but I added just in case. I don't want to cause any security issues to people's servers. Thanks for the feedback
    – negletios
    Sep 20, 2014 at 22:42
  • Sure, my pleasure. It's just risky without a good reason. Retracted my down vote now. Sep 21, 2014 at 9:13
1

There is an even more secure approach to setting up your Wordpress which doesn't involve passwords at all: use SFTP.

Basically, you'll need to do some set-up, and you'll need to be logged in as the Wordpress ftp user and in its home directory.

Start by creating a PKI key-pair (keygen-ssh prompts you through the process, this example assumes you've taken all the defaults):

keygen-ssh

Put the new keys where they need to go:

cat ip_rsa.pub >> .ssh/authorized_keys
mv ip_rsa* .ssh/

Change the protections (it's unclear why Wordpress requires this, but it does):

chmod 700 .ssh/
chmod 600 .ssh/*

Add the following lines to your wp-config.php:

define('FTP_HOST', 'localhost');
define('FTP_USER', '«your user name goes here»');
define('FTP_PUBKEY', '«full path to user's home directory»/.ssh/wp_rsa.pub');
define('FTP_PRIKEY', '«full path to user's home directory»/.ssh/wp_rsa');

Make sure apache can get at the wp-content/ directory:

chmod 775 «full path to WordPress directory»/wp-content

I've outlined the entire process in detail in a posting on my blog.

0

"Could CloudFlare have anything to do with it?"

CloudFlare doesn't proxy ftp traffic & this is really generally going to be something to take up with your hosting provider.

1
  • Honestly, I am so surprised how many people are posting this 'answer'. You should NEVER store your ftp credentials on a (live) server!! I cannot count how many times we had to restore a server because it was hacked simply by harvesting ftp login data. Sep 1, 2015 at 8:58
0

Problem is that your server is executing different PHP protocol from the the one used by WordPress, i don't know how that happens. You can check PHP protocol you are running by looking into phpinfo() for a line SERVER API. Or if you have cPanel on your hosting, you can see How to enable suPHP in cPanel.

You do a workaround with FTP details in wp-config.php like so:

define('FTP_USER', 'username');
define('FTP_PASS', 'password');
define('FTP_HOST', 'ftp.example.org:21');

You can also define FTP_SSL, FTP_BASE, FTP_CONTENT_DIR and FS_METHOD if you need that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.