3

The admin/reports/updates/update page lists updates, and there's what looks like a handy button Download these updates at the bottom.

And then you're asked for your SSH user and password.

Now unless you're running over SSL, this is a massively daft thing to do. Provide your server credentials over plain http?

If Drupal really needs to do an SSH loopback (as the help text explains, it's highly likely that the webserver is the SSH server it will connect to) in order to run updates, then surely there ought to be a way to provide the webserver's user with a DSA key so that users don't need to pass credentials in plain text.

Is there a way? Or is this really as insecure as it looks!

(I generally use SSH and drush to do updates, but as there's a GUI there, which looks nice, I feel it ought to work)

2 Answers 2

7

I think you are right that it's asking you to enter your important credentials over a potentially non-encrypted channel. This feature is a trade-off between doing things an optimally secure way and making it easy to get updates done. If updates are hard to do people won't do them and that is also an insecure situation.

Entering your credentials over a non-encrypted channel is only insecure if you think someone is sniffing your traffic. You can mitigate that by using a vpn or ssh tunnel (especially one that goes to the server).

Your idea to upload your private ssh key to the webpage to avoid using credentials seems at least partially flawed to me: the private key has the same value to an attacker as your ssh username/password. If you send the key on a non-encrypted channel that can also be intercepted and abused.

If you are concerned about security you can:

  1. Add a full or self-signed ssl certificate to your webserver
  2. Use a vpn or ssh tunnel to encrypt your non-encrypted (http) browser traffic
  3. Just keep using ssh+drush to get the updates done
5
  • not sure you understood my idea. If you can assume that the user account that the webserver runs as, e.g. www-data, has enough privileges to complete an update, then all that is needed is for Drupal to be able to "log on" as itself via ssh, without a password. So in the user's home dir you create a SSH keypair, but append its own public key to the authorized_keys file. Then from the webserver, ssh www-data@localhost should work without a password. And if you only enable Drupal admin to perform this, it should be ok, no? Commented Apr 5, 2012 at 13:37
  • I'm not sure if that would work technically. However, putting SSH private keys onto the server in a directory that the webserver itself can read would be a very handy tool for an attacker of the site if that attacker gained partial access to the site (e.g. file inclusion but not php execution acces).
    – greggles
    Commented Apr 13, 2012 at 14:30
  • it's true, if an attacker gained access to file inclusion they could nab the private key. But you could set up ssh to only allow www-data to logon from localhost. But then I suppose the point of this is to be user-friendly and none of that is. So perhaps drupal could just do the updates without SSH - directly on its files? Commented Apr 13, 2012 at 14:58
  • Allowing the webserver to write to the files directly is a bit controversial. If you configure your server that way then Drupals updater will take advantage of it and do that. However, that also weakens the server in the case of an attack. I see it as a trade-off: it's important that people update quickly and letting the files be writeable helps that. On the other hand, in many environments it is better to do updates another way (e.g. revision control) and prevent editing files via the webserver process.
    – greggles
    Commented Apr 13, 2012 at 15:54
  • yep. agree, it's a trade off - trust Drupal to be bulletproof in terms of not destroying itself by overwriting its own files, or trust users to not use daft features such as entering server passwords over plain requests. As min. would expect them to put user warning on page if not running over https. Anyway, enough of my grumbling!, you've answered the question very clearly, so thank you. Commented Apr 15, 2012 at 19:39
0

Got it! Here's how to update your site at example.com over http, with your normal user name and password, but without sending these unencrypted. You will need access to SSH and to your (local) hosts file.

  1. Edit your local hosts file (/etc/hosts on Linux) adding example.com after the 127.0.0.1 localhost line. This will mean that when you access example.com, you're actually just accessing your own machine. Therefore, after doing this, you should not be able to access this website. Try it.

  2. At the command line, log on to your server with SSH, setting up a local port forward: ssh [email protected] -L 10022:localhost:80.

  3. You should now be able to access your site at http://example.com:10080. You can do the updates, and happily supply your username/password because although it's running over http, this traffic is being tunnelled over SSH to the server, so as long as example.com is the webserver, the only unencrypted bit is between SSH and (e.g.) Apache on the same machine; i.e. nothing goes across the internet unencrypted.

  4. Finally, exit the SSH session, and re-edit your hosts file.

Nb. editing the hosts file is necessary so that Apache (or whatever) knows which website you're accessing. If it only serves one site, you can probably skip the hosts bit and access the site at http://localhost:10080 instead.

3
  • 1
    This is not the answer to your original question. Your question was whether you could provide a key to Drupal to use for local ssh authentication and the answer there is a very clear "you could, but it's no better than providing username/password." This answer is a great answer to the question "I don't have ssl, how can I make a secure connection to my webserver as someone who has ssh access to the webserver?" I use that same trick for Jenkins and it's great, but it's not the answer to your original question.
    – greggles
    Commented Oct 19, 2012 at 13:10
  • No, I don't think so. The SSH key was a suggestion inside my question. I think this answers perfectly the problem set out in the title. Commented Oct 19, 2012 at 13:43
  • Well, there's only two question marks in your post. One of them was clear and I answered, the other wasn't clear what it referred to. Success is yours, I guess.
    – greggles
    Commented Oct 20, 2012 at 19:36

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.