Manage Users and Sudo on Ubuntu, Debian, AlmaLinux

Why user and sudo management matters on a VPS

If you manage users and sudo well, your VPS is easier to hand over, safer to patch, and far less likely to rely on shared root access. That matters whether you run one WordPress site, a reseller workload, or a small agency stack on a Hostperl VPS.

This is not just about convenience. Clear user separation gives you better audit trails, fewer lockout surprises, and a cleaner path during migrations. It also makes support easier when something breaks at 2 a.m., because the server history stays tied to named accounts instead of one shared login.

If you already use a control panel, this still matters. Panels such as cPanel, Plesk, and DirectAdmin sit on top of the OS, but the OS account model still decides who can patch, restart services, and fix permissions without guesswork. For account moves, our panel migration checklist and non-root sudo user guide cover the operational side in more detail.

Start with a simple rule: root is for recovery, not daily work

On a fresh server, use root only to create the first admin account, install packages, and recover access if something goes wrong. After that, day-to-day work belongs to a named user with sudo rights. That keeps your shell history cleaner and makes it easier to see who changed what.

• Use root for first boot tasks and emergency repair.
• Use one named admin account for updates, service restarts, and log checks.
• Use separate limited accounts for developers, editors, or agency clients.

For a business site, that separation is practical. A content editor should not need the same rights as the person handling Nginx reloads or database restarts. It reduces mistakes, and mistakes are what usually cause short outages.

How to manage users and sudo on Ubuntu and Debian

Ubuntu and Debian use the sudo group by convention. Install the tools, create the account, and grant membership there. If you are on a Hostperl VPS, this is usually the cleanest path for a small team or agency handoff.

On the VPS as root:

cat /etc/os-release

This confirms the distribution before you touch account settings. You should see Ubuntu or Debian fields in the output.

apt update

This refreshes package metadata so your admin tools and security fixes are current.

apt install -y sudo openssh-client openssh-server

This ensures sudo and SSH are available. If you are already connected over SSH, the server package is usually installed, but checking does not hurt.

adduser deploy

Create a named administrative account called deploy. The system will prompt for a password and basic user details. Replace deploy with the username you plan to use.

usermod -aG sudo deploy

This adds the account to the sudo group. After this, the user can run admin commands with sudo.

mkdir -p /home/deploy/.ssh

Create the SSH directory for the new user.

chmod 700 /home/deploy/.ssh

Lock down the SSH directory so only the owner can read it.

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

If you already use SSH keys as root, copy the public key authorization file into the new account. If you do not, paste the key manually instead.

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

Set ownership so the new account can use its keys.

chmod 600 /home/deploy/.ssh/authorized_keys

Restrict the key file so SSH accepts it.

On your local computer:

ssh deploy@203.0.113.10

Use the server's real public IP instead of 203.0.113.10. Keep the root session open until this login works.

On the VPS as the non-root sudo user:

sudo -v

This confirms sudo access before you rely on it. If you are prompted for a password and it succeeds, the account is ready.

Once that works, you can decide whether to disable root password login later. Do not do that until you have verified key-based access from a second terminal.

How to manage users and sudo on AlmaLinux and Rocky Linux

AlmaLinux and Rocky Linux use the wheel group instead of sudo by default. The workflow is the same, but the commands differ. That matters in mixed hosting fleets where one server runs Ubuntu and another runs an RHEL-compatible release.

On the VPS as root:

cat /etc/os-release

Confirm that you are on AlmaLinux or Rocky Linux before continuing.

dnf update -y

Bring the system current before changing access controls.

dnf install -y sudo openssh-clients openssh-server

Install the sudo and SSH packages if they are not already present.

useradd -m deploy

Create the deploy account with a home directory.

passwd deploy

Set a password if you want password-based recovery access. Many teams still keep key-based SSH as the primary login and a password only as a fallback.

usermod -aG wheel deploy

Add the account to the wheel group so sudo works.

mkdir -p /home/deploy/.ssh

Create the SSH directory.

chmod 700 /home/deploy/.ssh

Set restrictive permissions.

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

Reuse an existing SSH key if root already has one configured.

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

Set ownership to the new account.

chmod 600 /home/deploy/.ssh/authorized_keys

Lock down the key file.

On your local computer:

ssh deploy@203.0.113.10

Again, replace the example IP with the real VPS address. Test the login in a second terminal before you change root access.

On the VPS as the non-root sudo user:

sudo -v

If this succeeds, the account is ready for operational use.

Make sudo practical for real hosting work

Most people think of sudo as a security feature. It is that, but it is also an operational record. If your agency changes PHP settings, restarts MariaDB, or tweaks a firewall rule, the command trail should point to one named admin account.

That is useful during support calls. It is also useful during migrations. When a customer says a site slowed down after a move, the question is not just what changed. It is who changed it and when.

• Use sudo systemctl restart nginx or the relevant service name, rather than switching into root for every task.
• Use sudo journalctl -u service-name -n 50 for recent logs.
• Use one admin account per person when multiple staff touch production.

For agencies, this also keeps offboarding simple. Remove one user, revoke one key, and you are done. You do not need to audit a shared root password that five people learned months ago.

What to avoid when you manage users and sudo

The mistakes are usually small. They become expensive only when you need access urgently.

• Do not leave password logins wide open after key-based access is working.
• Do not give every developer full root rights if they only need web file access.
• Do not copy SSH keys without checking ownership and permissions.
• Do not disable root until a second terminal proves the new account works.

On RHEL-compatible servers, remember that membership in wheel is the gatekeeper. On Debian-based systems, the sudo group is the standard path. Mixing those assumptions is one of the fastest ways to create a support ticket.

Verification that catches problems early

Before you hand the server back to a customer, verify access from both sides. You want to know the account works, sudo works, and SSH still accepts the expected key.

On the VPS as root:

id deploy

This should show the user and its supplemental groups, including sudo or wheel.

getent group sudo

On Ubuntu and Debian, this confirms membership in the sudo group.

getent group wheel

On AlmaLinux and Rocky Linux, this confirms wheel membership.

On the VPS as the non-root sudo user:

sudo whoami

The output should be root. That tells you sudo is working as intended.

ls -ld ~/.ssh ~/.ssh/authorized_keys

You should see strict permissions, not world-readable files.

On your local computer:

ssh deploy@203.0.113.10

Successful login from a fresh terminal is the real test. If this works, you have a usable admin account for ongoing VPS work.

How this helps migrations, support, and recovery

A tidy account model speeds up almost every support task. During a migration, you can hand over a clear admin login to the next operator. During a restoration, you can verify whether the correct user owns the web files. During a security incident, you can disable one account without breaking everyone else.

That is why Hostperl treats this as part of normal server readiness, not a niche hardening exercise. If you are launching on a managed VPS hosting plan or scaling into a dedicated box later, the same user structure carries forward cleanly. It makes handoffs smoother and cuts down the time spent hunting through permissions after a launch.

If you want the next logical step, pair this setup with our SSH, UFW, and Fail2Ban guide and the initial VPS setup guide. Together, they give you a stronger baseline for production use.

FAQ

Should I use one admin user or several?

Use one admin account per person whenever more than one operator touches production. Shared accounts make audits and offboarding harder.

Should I disable root login after creating sudo access?

Only after you confirm SSH key login and sudo work from a second terminal. Keep the root session open until then.

Why does Ubuntu use sudo while AlmaLinux uses wheel?

That is the default group model for each family. Ubuntu and Debian standardize on sudo; AlmaLinux and Rocky Linux typically use wheel.

What should I check if sudo says the user is not in the sudoers file?

Run id username and confirm group membership. Then add the account to sudo or wheel, depending on the distribution, and open a new shell.

Can I use this setup for a control panel server?

Yes. cPanel, Plesk, and DirectAdmin still rely on the underlying OS account model for maintenance and recovery tasks.