When to disable root account on ubuntu server
Solution 1:
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.
Solution 2:
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.
Solution 3:
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!
-
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 -
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.