I've set up Ubuntu 20.xx as a web server in the cloud provided by Digital Ocean and wish to install Node, Express, Mongo and possibly NginX. In several articles there is mention of disabling root user to improve security and create a new user with administration access. In order, I created a new user and then used this to set-up all applications but ran into issue with nginx.

Should I instead use root user to set-up all applicatons first, and allow applications to run under root ? Then create a second admin user with ssh access and then disable ssh for root?

UPDATE1: Thanks for your assistance all, I've updated the question and added its a cloud install.


Thanks for the detailed explanation. As I understand it :

  1. A Sudo user has the same privileges as root
  2. A Sudo user can be tracked who performed actions (of relevance when multiple users are concerned)
  3. Web applications (node, pm2, mongo) can be installed EITHER with root account and/or sudo user accounts, because these applications should run with their own default user accounts.
  4. Disable root ssh in due course to protect against brute force attacks

3 Answers 3


On a stock install of Ubuntu Server on bare metal or a self-hosted VM, the root user is already disabled. DON'T enable root. Use Ubuntu the way that it's designed to be used.

On a cloud install of Ubuntu, you're not installing; the finished container/VM is handed to you. Cloud users often have a functioning root prompt so they can create admin sudo users. Advice: After you create those users and install their SSH keys, disable root login (and all password login) to protect your system from attackers.

If you are encountering a problem with nginx, please open a new question specifically about that problem.

  • I'm using Digital Ocean image and root is enabled. There's an article that explains how to create a new user and disable root - digitalocean.com/community/tutorials/… Dec 26, 2021 at 18:18
  • Question is which account should be used to install and run Node.Js Mongo and PM2. Thanks Dec 26, 2021 at 18:27
  • 1
    Your comment question (and the original) shows a fundamental lack of understanding of why root should be disabled and what sudo does in its place. What account is used to install is moot. What account to run applications should be moot, or part of the boot scripts to start them.
    – user10489
    Dec 26, 2021 at 21:06
  • Your question did not make clear that this was a cloud instance. There are some differences between cloud instances and bare-metal/VM installs. Big edit to address.
    – user535733
    Dec 27, 2021 at 3:02
  • Thanks, I've updated question after your feedback. Dec 27, 2021 at 9:55

The reason for "disabling root" and using sudo with a regular account instead has multiple purposes, none of which affect the answer to your question.

System software is always installed as root. Sometimes application software is installed as an application specific user, but typically not. Disabling login for the root account doesn't change this, and it doesn't change how applications are started at boot.

The point of disabling the root account is so that you log in as a normal user and do user session like things as a normal user and not root. Then you use sudo to elevate to root to install software and do other dangerous things. This also has the side effect that when you use sudo, the user account that did this is also logged, which is not that interesting unless there are multiple user accounts that can use sudo, in which case, it is easier to assign blame when a mistake is made. So installing software is still done as root -- just via sudo instead of direct login.

When an application (like NginX, mysql, mogodb, etc.) is configured to start at boot, typically the systemd (or initd) boot scripts start the application as a special application user. This user is created when the application is installed. You should not be starting the application by hand, but allowing the installed system scripts to start it (for instance with systemctl start ...) so that it runs with the correct permissions in the correct environment. The design philosophy behind this is that the application is isolated within its own user, and security issues with the application will (hopefully) be trapped in that user id. Most applications should not be run as root directly.

Having said all this, on a system with a single administrator, logging who uses sudo is less interesting, and if you have cloud images that you can just zap and reload from a fresh copy, what user you run things as inside the container is also less important. This is probably why your cloud image comes with root enabled and no separate administrative user.

  • Thanks for the explanation, I've updated question with my understanding - do you have any comments on this? Dec 27, 2021 at 9:53
  • Almost. sudo account is not the same as root. The account with sudo access has the permissions of a normal account except that it can run sudo to become root. It's not that the sudo account and root account are the same, it's that the sudo account can run things as root using sudo.
    – user10489
    Dec 27, 2021 at 13:15
  • When a new user is created (sudo or non-sudo) a directory is also created in the home directory with the user name. When web applications are installed using this new account, will this new directory be involved in anyway for the installation or does it only hold specific information for the user? Dec 27, 2021 at 14:33
  • That depends on the installation. For instance, if you install software using sudo apt install it doesn't use anything from the user's directory.
    – user10489
    Dec 27, 2021 at 18:41

When to disable root account on ubuntu server?

I would suggest not doing that but doing things to maximize security. Let's face it, if a government wants into your server, they will use an easy way to see your files. We only worry about the hackers out there.

I have an instance on RamNode I use for my websites. When I first learned how to setup an unattended Ubuntu server, I discovered several important things. As fast as you setup the server, someone will be trying to hack in!

  1. Create a strong root password. It should be at least 32 characters long. Do not duplicate keys next to each other. Use all of the character keys on the keyboard in a random selection except the backtick ' key. Use special characters like $%& and don't use any words or phrases. I store my login data like this in a text file on my primary computer: ssh [email protected] 6^g0)6)nS3@sGh^7*9L:pR%bS@3d9

  2. As soon as you have created your server, do this: ufw allow ssh ufw enable apt update apt list --upgradable apt upgrade

You have now locked out everyone trying to shell into your root and updated your Ubuntu files. No other ports are opened to allow any other access but ssh.

I also only use ipv4 so I lockout ipv6 access via the sshd_config file, the /etc/default/ufw file, and the /etc/default/grub file.

To see who is attacking you use this command: service sshd status You may be surprised to see how quickly they start trying to shell into your server. I get hit from China almost non-stop. The CCP has been stealing data from anywhere it can for decades. But that's another story.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .