Great suggestion we had another request for this and we will implement for customers that are no longer trial accounts.

This is really important, and adding a checkbox really isn't enough. Best bet is to disable sending root passwords by email entirely.

Also please note that if you use SSH keys we do not email any root passwords.

You could have as a creation requirement the pasting of a ssh public key, and have that inserted into the /root/.ssh/authorized_keys file. Also reset the defaults of sshd_config to "UsePam no"

Using SSH keys with the control panel currently you will not be emailed a root password as the SSH keys are used instead.

I think the better way will be work with SSH keys too. It will improve secure and will be easier.

Since there's quite a few comments on this one, I'll ask. Why does it matter if the default root password is sent via e-mail when your Droplet is setup?

Changing the root password for any VPS, whether the password is sent via e-mail or not, should be one of the first steps you take before doing anything else. The passwords that are sent out are short, and while semi-random, are not, in my opinion, meant to be used except to gain first-time access.

This is simply standard protocol. Changing any password you're provided with is always a best-practice, regardless of whether it's a root password, or password for another service :-).

This one is a tough call our policy is what Jonathan outlined - basically if you aren't using SSH keys we recommend updating the root password after you receive it.

For any kind of automated provisioning SSH keys are the preferred method.

And overall SSH keys are many times more secure than any form of a root password which should only be used for console access.

SSH Keys are great, though disabling root log-in altogether is also a best-practice. Simply create an unprivileged user, give the user the ability to switch to root via su / sudo, and test that it works.

If you're extremely concerned about security, there's always two-factor authentication, which can be done through various methods, though one I've been testing is Duo Security.

https://www.duosecurity.com/

You'll need a little time to do the setup, though two-factor is much more secure. Of course, if you're on an already compromised system, none of the three options really matter as a simple backdoor will circumvent them all.

We're going to move ahead with this one and move it to the planning stage.

Thanks for the feedback!

I disagree. The first thing the user should do is IMMEDIATELY change the root password to something high security (in fact, you shouldn't be logging in with root anyway).

Emailing it in plaintext encourages changing it right away.

In fact, key-only should be the default. This is a much more secure setup. If you want password auth, you should have to go out of your way to enable it.

I use ssh keys wherever possible for my server administration. I was very happy to find that adding an ssh key in the panel prior to deployment causes the random root password not to be e-mailed. Upon deploying my droplet, the first thing I did was to login as root using my ssh key, create a non-privileged user and allow that user sudo when needed. It is then possible to entirely disable password login as root using the standard sshd configuration from within the VM. If desired, I can even copy my authorized ssh key to my non-privileged user account and use it to login without a password as the normal user as well, thereby only requiring a password to execute commands with sudo.

Has there been any progress on this? While I agree it should be routine to change the root password on a new install. In the scenario where you are being actively targeted someone could be monitoring your email/network and have malware deployed to the server before you've even read the email.

This is already an option; simply by setting up SSH keys & saving them to your DigitalOcean Control Panel:

1.) https://www.digitalocean.com/community/articles/how-to-use-ssh-keys-with-digitalocean-droplets

2.) https://www.digitalocean.com/community/articles/how-to-create-ssh-keys-with-putty-to-connect-to-a-vps (see the "Automate the Creation of New Droplets" section)

Or, you can go the secure route: https://www.digitalocean.com/community/articles/how-to-use-ssh-keys-with-digitalocean-droplets

This really made me freak out when I created my first droplet! Sending out a root password via email, seriously?

The saddest part is that the people that *DO* understand the security risk would immediately change/disable root password, but regular people would just keep the root access hanging in their gmail inbox!

Please address this issue responsibly.

Since one can always get shell access via web panel in case they lock themselves out of the box, there's really no reason to use passwords at all by default.

I believe new images (at least one I deployed recently, even from a snapshot), force you to change the root password upon logging into SSH for the first time... so probably a moot point now, since you are forced to change it to your own unique password upon first use of the droplet.

However, either displaying it in the web browser (like another digital ocean competitor) upon creation of the droplet would be handy either by default, or as an option (checkbox) during creation could still be handy, especially if we don't want it in our email at all, instead, if sending an email, maybe just provide a link to a knowledgebase article with instructions on resetting the password if you lose it/forget it/otherwise can't login.