Create a non-root sudo user on a VPS and why root login is risky

Logging in as root is like walking around with the master key in your hand: fast, powerful, and one mistake away from breaking the whole place.

Short version: To create a non-root sudo user, you make a normal user account, give it permission to run admin tasks with sudo, test that login, and only then reduce or disable direct root access. This makes day-to-day server work safer because ordinary commands run with ordinary permissions, while admin power is used only when you clearly ask for it.

What is a non-root sudo user?

root is the all-powerful administrator account on a Linux server. It can edit system files, delete applications, change security settings, and remove whole directories without asking whether you really meant it.

A non-root user is a regular account with limited power. Think of it like a staff badge instead of the building master key. You can enter the rooms you need, but you do not accidentally unlock everything with every move.

sudo means superuser do. It lets a trusted normal user run one command with admin power. Instead of living as the administrator all day, you step into admin mode for a specific task, then step back out.

That small pause matters. When you type sudo, you are making a conscious choice: this action changes the server.

Why is root login risky?

Root login is risky because every command runs with maximum power. There is no safety rail between a typo and a real system change.

If you are logged in as root, a mistaken delete, a bad file permission, or a pasted command from an old tutorial can damage the whole server. It is like cooking with the gas turned fully open: it may work, but there is no margin for clumsiness.

It is also a common target. Attackers know the username root exists on many servers, so they can focus on guessing keys, passwords, or weak access rules for that one account. A separate user with sudo does not solve every security problem, but it removes the most obvious front door.

This is why a sudo user belongs with other first security steps, like a firewall. If you have not done that yet, read how to set up a firewall on your server after you fix your login setup.

How do you create a sudo user safely?

The safe pattern is simple: create the new user, give it sudo rights, test it, then tighten root access.

On many Ubuntu or Debian servers, the flow looks like this:

bashadduser sam
usermod -aG sudo sam

Replace sam with the username you want. The first command creates the account. The second adds that account to the sudo group, which is the group allowed to run admin commands.

Next, make sure the new user can log in. If you use SSH keys, place the public key in that user account so the server recognizes you. Do not close your current root session yet. Open a second terminal window and test the new login first.

Then test sudo with a harmless admin command, such as checking for system updates. If it asks for the user password and runs correctly, the user has sudo access.

Only after that should you consider turning off direct root login for SSH. The key word is after. If you disable root login before testing the new account, you can lock yourself out and turn a five-minute security task into an emergency.

What can go wrong if permissions are messy?

The most common failure is this exact error: sudo: user is not in the sudoers file. It means the user exists, but the server has not been told that this user may run admin tasks. The fix is to add the user to the right sudo-capable group or sudoers rule from an account that already has admin access.

Another common problem is Permission denied (publickey). That usually means the server did not find a matching SSH key for the user you tried to log in as. The account may be fine, but the key is in the wrong place, has the wrong ownership, or belongs to a different user.

File ownership can also get confusing. If you create application files as root, then later run your app as a normal user, the app may not be able to write logs, upload files, or update itself. The server looks broken, but the real issue is that one user owns files another user needs.

When access gets confusing, logs often tell you where the failure is. If you are not used to reading them, this guide to reading server logs will help you separate login problems from application problems.

FAQ

Do I still need root at all? Yes, but you usually do not need to log in as root directly. Keep admin power available through sudo from a trusted user.

Should every project have its own user? Often, yes. Separate users help stop one project from writing into another project’s files by accident.

Is sudo safer than root? Sudo is safer for daily work because admin power is temporary and intentional. It is not magic protection, but it reduces careless damage.

Can I disable root login immediately? Not until you have tested the new sudo user in a separate login session. Otherwise you may lock yourself out.

The shortcut

Server Manager helps by keeping this access setup visible instead of buried in memory and scattered notes. The outcome is that you can see which user is meant to manage the server, which projects belong where, and avoid the classic tangle where root owns files that an app user needs later.

It also reduces the chance of slow, awkward failures months from now: a project unable to write logs, a deploy blocked by permissions, or a setup no one remembers clearly. The real benefit is not skipping knowledge; it is keeping the server legible after the first setup day.

That matters most when you come back later to update an app, restore from a backup, or move a site. Your access model still makes sense, instead of feeling like a locked door with three mystery keys. For the restore side of that picture, keep your server backups restorable, not just created.

What does a safer login setup give you?

A non-root sudo user gives you a calmer way to manage your server. You still have the power to install software, update services, and fix problems, but you are not carrying full administrator force into every command.

The win is simple: fewer dangerous accidents, fewer permission mysteries, and a setup you can understand when you return to it later.