How to create a non-root sudo user

A fresh VPS usually gives you exactly one account: root, which can do absolutely anything to the system with no restriction and no warning. That is fine for the first few minutes of setup, but using it as your everyday login is a habit worth breaking immediately — a mistyped path in a command run as root has no safety net, while the same mistake as a limited user is usually stopped cold by a permissions error.

The fix is a personal account with sudo rights: your own login, your own shell history, and administrative commands available one at a time by explicitly asking for them.

Create the account

On Ubuntu and Debian, adduser is the friendlier option — it is interactive and sets up a home directory, a password, and some sensible defaults in one go:

sudo adduser yourname

You will be prompted for a password and some optional details (full name, and so on) — the optional fields can be left blank by pressing Enter.

On RHEL, Rocky Linux and AlmaLinux, useradd is the standard tool and is more manual — it does not set a password or prompt for anything by default:

sudo useradd -m yourname
sudo passwd yourname

The -m flag creates the home directory; without it the account exists but has nowhere to put its own files, including its SSH configuration.

Grant sudo rights

Add the new account to the group that is permitted to use sudo. The group name differs by distribution family:

sudo usermod -aG sudo yourname      # Ubuntu / Debian
sudo usermod -aG wheel yourname     # RHEL / Rocky / AlmaLinux

Copy your SSH key to the new account

If you already have key-based login working for root, carry the same key over rather than setting up password login for the new user. As root, or using sudo:

sudo mkdir -p /home/yourname/.ssh
sudo cp ~/.ssh/authorized_keys /home/yourname/.ssh/authorized_keys
sudo chown -R yourname:yourname /home/yourname/.ssh
sudo chmod 700 /home/yourname/.ssh
sudo chmod 600 /home/yourname/.ssh/authorized_keys

The permissions matter more than they look like they should: SSH silently refuses to use an authorized_keys file, or its containing directory, if either is writable by anyone other than its owner. 700 on the directory and 600 on the file are the values SSH expects.

Test the new account before relying on it

Open a completely new terminal window — do not close your existing root session yet — and log in as the new user:

ssh yourname@203.0.113.10

Confirm you land in a shell with no password prompt, then confirm sudo actually works:

sudo whoami

That should print root. If it asks for a password you have not set, or refuses outright, the group membership did not take — log back into your working root session and double-check the usermod command above, including that you spelled the group name correctly for your distribution.

Reducing how often sudo asks for a password

By default, sudo asks for the user's own password (not root's) and then remembers it for a short window, usually fifteen minutes. That is a reasonable default and there is rarely a good reason to change it — extending or removing the timeout trades a small amount of convenience for a meaningfully larger window in which a hijacked, unattended session has unrestricted root access.

Auditing who actually has sudo access

On a server that has existed for a while, it is worth checking exactly who currently has administrative rights rather than assuming you remember. List members of the relevant group directly:

getent group sudo      # Ubuntu / Debian
getent group wheel     # RHEL / Rocky / AlmaLinux

Anything you do not recognise on that list is worth investigating — a contractor's account left active after a project ended is a common, entirely avoidable source of unnecessary risk. Remove access from an account without deleting it outright, if you might need the audit trail later:

sudo deluser yourname sudo      # Ubuntu / Debian
sudo gpasswd -d yourname wheel  # RHEL / Rocky / AlmaLinux

Removing an account entirely

When someone genuinely no longer needs access to the server at all, remove the account rather than merely disabling its password — a stale, unused account is one more thing that could theoretically be compromised:

sudo deluser --remove-home yourname      # Ubuntu / Debian
sudo userdel -r yourname                 # RHEL / Rocky / AlmaLinux

The --remove-home and -r flags also delete the account's home directory. Skip them if you want to keep the files for reference, though at that point consider whether they contain anything that ought to be archived elsewhere instead of left on a live server under an account that no longer exists.

What to do with root once this is done

Do not delete the root account — several system processes still rely on it existing. Instead, stop using it for anything routine:

• Disable direct root login over SSH by setting PermitRootLogin no in /etc/ssh/sshd_config, covered in securing a new Linux server.
• Use sudo -i from your own account on the rare occasion you genuinely need a full root shell, rather than logging in as root directly.
• Keep your day-to-day account's own password or key as the only way in, so every login is tied to an identifiable person rather than a shared, all-powerful credential.

Once this is in place, the next step is usually locking down the firewall — see setting up a firewall on your VPS — and, if you have not already, moving SSH entirely to key-based login as covered in connecting to a VPS over SSH.