How to Create a Non-Root Sudo User on a VPS

Fresh VPS images often drop you straight into root, and it's tempting to just stay there. Don't. Working as root means every typo can be catastrophic and every compromised process has total power. The fix is a dedicated user with sudo for when you genuinely need admin rights. This is one of the first things to do on any new server.

Why not just use root?

Root has no guardrails. A mistyped rm, a malicious script, or a compromised process running as root can destroy or take over the whole machine. A normal user with sudo gives you the same capabilities *when you ask for them*, plus an audit trail of what was run with elevated privileges. It's the principle of least privilege in practice.

Step 1: create the user

On Ubuntu/Debian, adduser sets up the account, home directory, and password interactively:

adduser deploy

Set a strong password when prompted (you can leave the other fields blank). For a strong password, see how to generate a strong password.

Step 2: grant sudo rights

Add the user to the sudo group (wheel on RHEL-family systems):

usermod -aG sudo deploy

Step 3: give the user your SSH key

So the new user can log in with keys (see SSH key authentication), copy over the authorized keys. If you're currently root and want to reuse root's keys:

rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Or from your local machine:

ssh-copy-id deploy@your-server-ip

{{SCREENSHOT}}

Step 4: test sudo works

Log in as the new user in a fresh terminal and confirm you can elevate:

ssh deploy@your-server-ip
sudo whoami      # should print: root

If that prints root, the account has admin rights. This test matters — confirm it before you disable root login, or you risk locking yourself out.

Using sudo day to day

Prefix admin commands with sudo:

sudo apt update
sudo systemctl restart nginx

For a series of admin commands, open a root shell with sudo -i, but drop back to your normal user for everyday work. sudo also logs every elevated command to the journal — useful for auditing.

Optional: passwordless sudo (understand the trade-off)

For automation you may want sudo without a password prompt. Do it safely with a drop-in file validated by visudo:

echo 'deploy ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/deploy
sudo visudo -c

Always edit sudoers via visudo (or validate with visudo -c) — a syntax error in the sudoers file can lock everyone out of sudo. Note the trade-off: passwordless sudo means a compromised session gets root with no extra barrier. Prefer keeping the password prompt for interactive users.

Where this fits

Creating a sudo user is step one of server setup, right alongside SSH keys, disabling root login, and a firewall. Together they're the core of securing your first Linux VPS.

Fine-grained sudo: limiting what a user can run

Full sudo is right for your own admin account, but sometimes you want an account that can do exactly one thing — restart a service, run a deploy script — and nothing more. The sudoers file supports this precisely. Grant a user permission to run only specific commands as root:

# /etc/sudoers.d/deploy-restart  (edit via visudo)
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/systemctl status myapp

Now deploy can restart and check that one service without a password, but can't run arbitrary root commands. This is ideal for CI/CD accounts and teammates who need one narrow capability — least privilege applied to the elevation itself, not just the login. Always create these with sudo visudo -f /etc/sudoers.d/deploy-restart so the syntax is validated before it's saved; a broken sudoers file can lock everyone out of elevation at once.

Managing multiple users cleanly

As a team grows, keep user management tidy so access stays auditable. Use groups to grant capabilities rather than editing each user individually — put admins in sudo, deployers in a deploy group with narrow sudoers rules, and so on. Review who has access periodically:

getent group sudo        # who has full admin rights?
lastlog                  # when did each account last log in?

When someone leaves, disable their account promptly with sudo usermod -L username (locks the password) and remove their SSH keys from authorized_keys — locking the password alone doesn't stop key-based login. An account nobody uses is pure attack surface, so pruning dormant users is part of good hygiene. Combined with per-person logins and the sudo audit trail, this keeps a shared server accountable: you always know who can do what, and who did what.

FAQ

sudo group or wheel group?

On Debian/Ubuntu the admin group is sudo; on RHEL/CentOS/Fedora it's wheel. Add your user to whichever your distro uses.

Do I lose any power by not using root?

No. sudo gives you full root capabilities on demand, with the bonus of an audit log. Use sudo -i for an interactive root shell when needed.

Is passwordless sudo safe?

It's convenient for automation but removes a safety barrier — a compromised session gets instant root. Keep the password prompt for interactive users; reserve NOPASSWD for specific automation needs.

What if I break the sudoers file?

Always use visudo, which validates syntax before saving. If you're already locked out, use your host's web console to log in as root and fix it.

The setup in four commands

Creating a proper admin user is quick, and the test at the end is what keeps you safe:

adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy
# then, in a NEW terminal:
ssh deploy@your-server-ip && sudo whoami   # must print: root

Once sudo whoami returns root, you have a working non-root admin account and can safely lock down root login. From here, work as this user day to day and elevate with sudo only when needed — you keep every capability root had, plus an audit trail of what was run with elevated privileges. For teams, use groups to grant access, review membership periodically with getent group sudo, and disable dormant accounts promptly. And always edit sudoers through visudo, which validates syntax before saving so a typo can't lock everyone out of elevation. These small disciplines keep a shared server both secure and accountable over time.

A non-root sudo user is the foundation of safe server administration. Get full root access to set it up your way — see Nxeon VPS hosting and our security page.