How to Create a Sudo User on Ubuntu (and Disable Root Login)

Introduction

If you run a VPS or dedicated server, the very first thing you should do after logging in is stop using the root account for daily work. Root has unlimited power, so one typo can wipe your entire system, and brute-force bots constantly hammer root logins over SSH.

The professional pattern is simple: create a dedicated administrative user, give it sudo privileges so it can run admin commands with a password check, and then disable direct root login. In this guide you will do exactly that on Ubuntu 24.04 or 22.04, step by step, with every command explained.

Prerequisites

• An Ubuntu 24.04 or 22.04 server (VPS, cloud instance, or local machine).
• You are currently logged in as root (or as a user that already has sudo access).
• Basic comfort with the Linux terminal.
• A terminal or SSH client (PuTTY, Windows Terminal, or the ssh command).

Step 1 — Create the new user

Ubuntu's adduser command creates the account, its home directory, and prompts you for a password in one go. Replace deployer with the username you want.

adduser deployer

You will be asked to set a password and fill in optional details (name, phone, etc.). The details can all be left blank by pressing Enter. Pick a strong password — this account will have full admin power.

adduser vs useradd: adduser is the friendly interactive wrapper; useradd is the low-level tool that skips the prompts and home-directory setup. On Ubuntu, always use adduser for manual account creation.

Step 2 — Add the user to the sudo group

On Ubuntu, membership in the sudo group is what grants administrative privileges. The -aG flags append the user to the group without removing existing memberships.

usermod -aG sudo deployer

Verify the group membership took effect:

id deployer

The output should list sudo among the groups, e.g. groups=1001(deployer),27(sudo). You can also check exactly which commands the user may run:

sudo -l -U deployer

This should show (ALL : ALL) ALL, meaning the user can run any command as any user after authenticating.

Step 3 — Test sudo access before locking anything down

Never disable root access before you confirm the new account works. Switch to the new user and run a harmless admin command:

su - deployer
sudo whoami

The first time you run sudo, you will be asked for the user's own password (not root's). sudo whoami should print root, proving elevation works. Also confirm you can update the package lists:

sudo apt update

If that succeeds, exit back to your root session with exit. Your new admin account is fully functional.

Step 4 — Harden SSH: disable direct root login

Most attacks against Linux servers are automated bots trying root logins over SSH. Since you now have a sudo user, the root account no longer needs SSH access at all.

First, back up the SSH server config in case you need to roll back:

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Open the config file and find the PermitRootLogin line. If it is commented out, change it to no:

nano /etc/ssh/sshd_config

Set this line (uncommented):

PermitRootLogin no

While you are in there, consider also enforcing key-based authentication later — but for now, validate the config and restart SSH so the change takes effect:

sshd -t
systemctl restart ssh

sshd -t tests the configuration syntax; if it prints nothing, the config is valid. systemctl restart ssh reloads the SSH daemon (the service is called ssh on Ubuntu).

Do not close your current root session yet. Open a second terminal and log in as the new user first. That way, if something is misconfigured, your original root session is still available to fix it.

Step 5 — Lock the root account password (optional but recommended)

Disabling SSH root login stops remote logins, but locking the root password prevents anyone from switching to root with su:

passwd -l root

This adds a ! in front of the password hash in /etc/shadow, disabling password authentication for root while keeping the account itself intact. Your sudo user can still elevate with sudo — that mechanism does not need the root password at all.

Step 6 — Verify it worked

Run these checks to confirm the hardening is in place:

1. Log in as the new user over SSH in a fresh terminal: ssh deployer@your-server-ip. It must succeed.
2. Confirm root SSH login is rejected: ssh root@your-server-ip should fail with Permission denied.
3. Confirm the config is active:

   sudo grep -i permitrootlogin /etc/ssh/sshd_config

   It should show PermitRootLogin no.
4. Confirm sudo still works as the new user: sudo apt update.

Once all four checks pass, you can safely close your old root session.

Common issues & fixes

"deployer is not in the sudoers file"

You skipped Step 2, or the group change has not taken effect in an existing session. Re-run usermod -aG sudo deployer as root, then log out and log back in as the user. Note: usermod -G sudo deployer (without -a) removes the user from all other groups — always use -aG.

"Permission denied (publickey)" when logging in as the new user

If your server only allows SSH key authentication, a password alone will not work for the new account. Copy your public key into the new user's authorized keys file:

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

Locked out after disabling root login

This happens when root was the only working account and the new user's login fails. Recovery: use your hosting provider's web console (most VPS providers offer one) to log in as root directly, restore the backup with cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config, and restart SSH. This is why Step 4 told you to keep a root session open.

sudo asks for the password too often (or never)

By default sudo remembers your authentication for 15 minutes. To change it, run sudo visudo and add a line like Defaults timestamp_timeout=30 for 30 minutes. Always edit sudoers with visudo — it validates the syntax and refuses to save a broken file that could lock you out.

Forgot the new user's password

Log in as root (or via the provider console) and reset it with passwd deployer. The root account itself remains usable for this because passwd -l only locks password authentication, and you can unlock it again with passwd -u root if you ever need direct root access.

Bonus: enforce SSH key-only login (recommended)

With root login disabled, the next hardening step is to stop password logins entirely and require SSH keys. First make sure your public key is in ~/.ssh/authorized_keys for the new user (see the "publickey" fix above), log in with the key to confirm it works, then set PasswordAuthentication no in /etc/ssh/sshd_config, run sshd -t, and restart SSH. Password-guessing bots become completely harmless.

Pair this with automatic security updates (sudo apt install unattended-upgrades) and your Ubuntu server will stay patched without you lifting a finger.

Conclusion

You now have a properly secured Ubuntu server: a dedicated sudo user for daily administration, root locked out of SSH, and a verified rollback path. This single change blocks the vast majority of automated attacks against your server.

Setting up servers securely is what we do every day — if you would rather have experts handle your Ubuntu server setup, hardening, and maintenance, XpertBees can take it off your plate.