DigitalOcean home
  • Droplets
  • Spaces
  • Kubernetes
  • Tools & Integrations
  • One-click Apps
  • API Documentation
  • Community
  • Tutorials
  • Q&A
  • Projects
  • Meetups
  • Customers
  • Pricing
  • Docs
  • Support
  • DigitalOcean home
  • Products
    • Droplets

      Scalable compute services.

    • Spaces

      Simple object storage.

    • Kubernetes

      Run managed Kubernetes clusters.

    • Tools & Integrations

      Automate your infrastructure.

    • One-click Apps

      Deploy pre-built applications.

    • API Documentation
  • Customers
  • Community
    • Community Overview

      Connect, share and learn

    • Tutorials

      DevOps and development guides

    • Questions & Answers

      Development and systems Q&A

    • Projects

      Community-built integrations

    Get Involved
    Write for DOnations
    Join us at a Meetup
    Featured Post
    An Introduction to Kubernetes

    by Justin Ellingwood

  • Pricing
  • Docs
  • Support
    • Documentation

    • Contact Support

    • Network Status

  • Home /
  • DO-I-2674 /
  • New idea
186 Vote

Display root password in control panel, not email

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!

  • K White
  • Sep 11 2018
  • Future consideration
Droplets
  • Comments (26)
  • Votes (186)
  • Attach files
  • Ritchie Villavicencio commented
    7 Feb, 2019 04:05am

    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

  • Moisey Uretsky commented
    11 Sep, 2018 07:29pm

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

    ×

    Attachments Open full size

  • Anonymous commented
    11 Sep, 2018 07:29pm

    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

  • Moisey Uretsky commented
    11 Sep, 2018 07:29pm

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

    ×

    Attachments Open full size

  • Sean commented
    11 Sep, 2018 07:29pm

    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

  • Moisey Uretsky commented
    11 Sep, 2018 07:29pm

    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

  • Junior Grossi commented
    11 Sep, 2018 07:29pm

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

    ×

    Attachments Open full size

  • Jonathan Tittle commented
    11 Sep, 2018 07:29pm

    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

  • Moisey Uretsky commented
    11 Sep, 2018 07:29pm

    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

  • Jonathan Tittle commented
    11 Sep, 2018 07:29pm

    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

  • Moisey Uretsky commented
    11 Sep, 2018 07:29pm

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

    Thanks for the feedback!

    ×

    Attachments Open full size

  • Sasha Shepherd commented
    11 Sep, 2018 07:29pm

    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

  • Cameron Eagans commented
    11 Sep, 2018 07:29pm

    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

  • Anonymous commented
    11 Sep, 2018 07:29pm

    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

  • Anonymous commented
    11 Sep, 2018 07:29pm

    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

  • Pablo commented
    11 Sep, 2018 07:29pm

    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

  • Pablo commented
    11 Sep, 2018 07:29pm

    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

  • Dmitry Pashkevich commented
    11 Sep, 2018 07:29pm

    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

  • Dmitry Pashkevich commented
    11 Sep, 2018 07:29pm

    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

  • Tyler commented
    11 Sep, 2018 07:29pm

    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

  • Load older comments
  • Avatar160.e35e46fe62a53e488ef9451dd1d3432e
  • +86
Log in / Sign up

Identify yourself with your email address

Subscribe

You won't be notified about changes to this idea.

Related ideas

Busy.b7e3690b94c43e444483fbc7927a6a9a
DigitalOcean home

© 2018 DigitalOcean, LLC. All rights reserved.
Proudly made in NY

  • Twitter
  • Facebook
  • Instagram
  • YouTube
  • LinkedIn
  • Glassdoor
Company
About
Leadership
Blog
Careers
Partner Network
Referral Program
Events
Press
Legal & Security
Products
Droplets
Spaces
Kubernetes
Tools & Integrations
One-click Apps
API
Pricing
Documentation
Release Notes
Community
Tutorials
Meetups
Q&A
Write for DOnations
Droplets for Demos
Hatch
Shop Swag
Research Program
Currents Research
Open Source
Support
Contact Support
FAQ
Network Status