It would be *much* better to have a checkbox option at instance creation time to only generate/display root password on-screen, but not send via (plaintext) email. Much more secure.
Also, a key-only (e.g., no passwords allowed) checkbox option for VM access would be awesome.
Thanks!
what you really need is to learn how to use ssh keys, passwords are insecure and also make you lose more time. just set an ssh key and select that key when you create a new droplet. you don't even need to wait for that email anymore.
Attachments Open full size
Great suggestion we had another request for this and we will implement for customers that are no longer trial accounts.
Attachments Open full size
This is really important, and adding a checkbox really isn't enough. Best bet is to disable sending root passwords by email entirely.
Attachments Open full size
Also please note that if you use SSH keys we do not email any root passwords.
Attachments Open full size
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"
Attachments Open full size
Using SSH keys with the control panel currently you will not be emailed a root password as the SSH keys are used instead.
Attachments Open full size
I think the better way will be work with SSH keys too. It will improve secure and will be easier.
Attachments Open full size
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 :-).
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
We're going to move ahead with this one and move it to the planning stage.
Thanks for the feedback!
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
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)
Attachments Open full size
Or, you can go the secure route: https://www.digitalocean.com/community/articles/how-to-use-ssh-keys-with-digitalocean-droplets
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size