How to Add a New Sudo User on Linux VPS Servers

Add a sudo user before you do anything else

The safest first change on a fresh VPS is to add a sudo user and verify it before you touch SSH hardening, firewall rules, or application installs. That gives you a working fallback if root login gets restricted later, and it matches the setup Hostperl support teams expect on production servers. If you are setting up a long-lived VPS, Hostperl VPS plans give you room for a clean admin account, separate app users, and sensible backups from day one.

This is practical, not theoretical. Agencies need a named admin for handoffs. Small businesses need a log trail that shows who changed what. And if you later migrate WordPress, a panel account, or a database service, a non-root sudo user keeps the work organized.

Why a separate admin account reduces hosting mistakes

Root access is powerful, but it leaves no margin for carelessness. A typo in a root session can change ownership on the wrong directory, stop the wrong service, or lock you out of SSH entirely. A sudo user cuts that risk because you start as a normal account and elevate only when needed.

It also makes support easier. When customers open a ticket after a migration, the first thing we usually ask for is the username they use to administer the server. A dedicated admin account speeds up that exchange and keeps the original root password out of daily use.

• Access control: only trusted admins get sudo.
• Audit clarity: commands run through sudo are easier to trace.
• Safer handoffs: agencies can transfer ownership without sharing root credentials.
• Better recovery: if one account is compromised, you do not have to reset everything.

Ubuntu and Debian: the cleanest path for a new admin account

On Debian-based systems, the usual path is straightforward: create the user, add them to the sudo group, and set up SSH keys before you consider turning off root password login.

For a quick comparison with other server setup decisions, see Manage Users and Sudo on Ubuntu, Debian, AlmaLinux. It covers the permission model in more detail, but the core idea is the same: get the new account working first, then tighten access.

Use the following sequence on a fresh Ubuntu or Debian VPS.

ssh root@203.0.113.10

That IP is only a documentation example. Replace 203.0.113.10 with your own server’s public IP.

cat /etc/os-release

This confirms whether you are on Ubuntu or Debian before you use distro-specific commands.

adduser deploy

Create the non-root admin account named deploy. You will be prompted to set a password and optional user details. If you do not want password login for this account, set a strong password anyway and disable it only after SSH keys work.

usermod -aG sudo deploy

This adds the new user to the sudo group so they can run administrative commands with sudo.

mkdir -p /home/deploy/.ssh

Create the SSH directory with the correct path for the new user.

chmod 700 /home/deploy/.ssh

SSH will ignore the directory if permissions are too open.

cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys

If the root account already uses SSH keys, this copies the same key to the new admin account. If you manage keys from your laptop, you can instead append the public key directly to this file.

chown -R deploy:deploy /home/deploy/.ssh

Make the new user the owner of their SSH directory.

chmod 600 /home/deploy/.ssh/authorized_keys

Restrict the key file so SSH accepts it.

Open a second terminal on your local computer and test the new account before you close the root session.

ssh deploy@203.0.113.10

Again, replace the example IP with your VPS address. If key-based login works, you should land in a shell without using the root password.

sudo -iu deploy

From the root session, this command is a quick local check that the account exists and sudo access is wired correctly. You should be prompted for the deploy password if password auth is enabled.

AlmaLinux and Rocky Linux: use wheel, not sudo

RHEL-compatible systems usually grant admin rights through the wheel group. The rest of the process is familiar, but the group name changes.

If you are building on a fresh Rocky Linux or AlmaLinux VPS, keep the original root session open until the second login works. That is the difference between a controlled setup and a lockout.

ssh root@203.0.113.10

Use your real server IP instead of the documentation example.

cat /etc/os-release

Check that you are on AlmaLinux or Rocky Linux before proceeding.

useradd -m deploy

This creates the deploy user and a home directory.

passwd deploy

Set a password for the new account. You can leave password login enabled during verification and disable it later if your SSH key workflow is ready.

usermod -aG wheel deploy

This grants sudo-equivalent privileges through the wheel group.

mkdir -p /home/deploy/.ssh

Create the SSH folder for keys.

chmod 700 /home/deploy/.ssh

Lock down the directory.

cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys

Reuse the key if root already has one. Otherwise, add your public key manually.

chown -R deploy:deploy /home/deploy/.ssh

Make sure the new user owns the files.

chmod 600 /home/deploy/.ssh/authorized_keys

SSH refuses overly permissive key files.

Now open a second terminal and test the new account.

ssh deploy@203.0.113.10

If key login succeeds, verify sudo with a harmless command such as sudo whoami. You should see root returned.

What to verify before you disable root login

Do not rush into SSH restrictions. The new account needs to be proven first. One failed verification is cheaper than a midnight recovery call.

• SSH login works with the new user.
• sudo prompts correctly and runs commands.
• Home directory ownership is correct.
• ~/.ssh/authorized_keys is readable only by the user.
• You still have an open root session as a fallback.

For a broader hardening sequence, Hostperl readers often pair this step with Set Up SSH, UFW, and Fail2Ban on a Fresh VPS. That guide is the natural next move once the admin account is in place.

Common mistakes that lead to lockouts

The errors we see most often are not exotic. They are small permission issues, the wrong group membership, or skipped verification.

• Wrong group: adding a user to sudo on AlmaLinux instead of wheel.
• Bad permissions: leaving ~/.ssh or authorized_keys too open.
• Home directory mismatch: copying files into the wrong path.
• Premature hardening: disabling root login before the new account works.
• No second session: making changes from a single SSH window and then losing access.

When a customer migration stalls, we usually ask them to check ownership and permissions first. In practice, that solves more access problems than password resets do.

How this fits real VPS operations

A clean admin account is not just a security habit. It sets the server up for better support, easier migrations, and safer maintenance. If you later deploy a control panel, a database service, or a reverse proxy, you already have a non-root user ready to own app files and run service commands.

That is one reason many Hostperl customers choose a VPS rather than forcing everything into a shared environment. You get room for sane account structure, predictable permissions, and a support workflow that does not depend on a single overused root login. If you are still comparing plans, managed VPS hosting gives you more control than shared hosting without the overhead of a full dedicated server.

FAQ

Should I disable root login right away?
No. Verify the new sudo user first, then disable root password login only after key-based access is confirmed.

Do Ubuntu and Debian use the same sudo group?
Yes. Add the user to sudo on both distributions.

Do AlmaLinux and Rocky Linux use sudo or wheel?
Use wheel for admin membership on both.

What if SSH key login fails?
Check file ownership, directory permissions, and the exact home path for the user before changing SSH settings.

Can I use the same key for root and deploy?
Yes, temporarily. For production, many teams later rotate to separate keys per admin.

Final verification and next steps

Before you move on, confirm the new account can log in, run sudo, and survive a reboot. Then keep the setup simple: one named admin, one known key, and a clear record of who owns the server. That is a better foundation for future work, from WordPress migrations to database tuning.

If you are planning the next stage of your build, Hostperl’s VPS hosting for Linux administration is a practical fit for this workflow, especially if you want room for staging, backups, and clean multi-user access.