Back to tutorials
Tutorial

Sudo Setup Guide Tutorial (2026): Create a Non-Root Admin User on a VPS and Lock Down Privileges Safely

Sudo setup guide tutorial for VPS admins: create non-root users, tighten privileges, log commands, and reduce root risk in 2026.

By Anurag Singh
Updated on Jul 07, 2026
Category: Tutorial
Share article
Sudo Setup Guide Tutorial (2026): Create a Non-Root Admin User on a VPS and Lock Down Privileges Safely

Root access makes fixes fast—and mistakes even faster. A clean sudo setup guide tutorial gives you a safer default. Work as a normal user, elevate only when you must, and keep an audit trail for privileged commands.

This walkthrough targets Ubuntu 24.04/26.04 LTS and Debian 12/13 on a hosting VPS. You’ll create an admin user, tighten sudo behavior, add guardrails for shared operations (resellers, dev teams), and confirm you can recover if something goes sideways.

What you’ll build (and why it matters on a hosting VPS)

  • A non-root admin account that handles packages, services, firewall rules, and web stacks without daily root logins.
  • A predictable sudo policy managed in /etc/sudoers.d/ (so you don’t risk the main file).
  • Better visibility with sudo logging and tighter command auditing for incident response.
  • Operational safety: you’ll keep at least one working access path if SSH, PAM, or sudo policy changes break something.

If you run customer sites, this is an easy way to shrink blast radius.

It also pairs well with a hardened baseline like the steps in HostMyCode’s server hardening tutorial.

Prerequisites and safe starting checks

Before you touch sudo, make sure you can get back in if you lock yourself out.

On a VPS, that usually means provider console access and a second SSH session you keep open while you work.

  • Keep one root SSH session open during changes.
  • Confirm you have provider console / recovery access for the VPS.
  • Know your distro: lsb_release -a (Ubuntu) or cat /etc/os-release (Debian).
# Baseline: who am I, what groups exist, is sudo installed?
whoami
id
command -v sudo || apt-get update && apt-get install -y sudo
getent group sudo 2>/dev/null || true
getent group wheel 2>/dev/null || true

On Ubuntu and Debian, the admin group is typically sudo.

On RHEL-family systems it’s often wheel.

The examples below use Ubuntu/Debian, but the model is the same.

Sudo setup guide tutorial: create a non-root admin user

Create a dedicated admin user tied to a real person (or a clearly defined role).

Skip generic names like admin on Internet-facing servers. They attract brute-force attempts. Pick something unique and easy to audit later.

# As root
adduser opsmia
usermod -aG sudo opsmia

Test in a separate terminal.

Keep your working session open.

su - opsmia
sudo -v
sudo whoami

sudo -v validates PAM and caches your credentials.

If sudo whoami prints root, elevation works.

Stop logging in as root (without breaking recovery)

After you confirm the admin user works, reduce root exposure.

On most hosting servers, that means disabling root SSH login.

Keep root available through the provider console and through sudo.

Edit /etc/ssh/sshd_config (or use a drop-in under /etc/ssh/sshd_config.d/ on newer Ubuntu):

# Prefer a drop-in file:
# /etc/ssh/sshd_config.d/99-root-login.conf
PermitRootLogin no

Reload SSH the safe way.

Validate first, then reload:

sshd -t && systemctl reload ssh

If you’re tightening firewall rules at the same time, slow down and verify each step.

HostMyCode’s UFW firewall configuration tutorial is a good companion because it focuses on not breaking SSH, web, and mail ports.

Configure sudo the safe way: /etc/sudoers.d and visudo

Don’t edit /etc/sudoers with a normal editor.

One syntax error can block sudo entirely.

Use visudo, and keep your changes in a dedicated file under /etc/sudoers.d/.

# Create a policy file for your admin role
visudo -f /etc/sudoers.d/10-ops-admin

Add:

# Members of sudo can run any command
%sudo   ALL=(ALL:ALL) ALL

Then lock the permissions.

Sudo ignores files that are too open:

chmod 440 /etc/sudoers.d/10-ops-admin

Quick validation:

sudo -l

Tighten sudo defaults for hosting operations (timeouts, env, and TTY)

Defaults are where you remove a lot of “quiet risk.”

These settings make escalation more intentional. They also reduce credential reuse on shared terminals.

visudo -f /etc/sudoers.d/20-sudo-defaults

Recommended baseline (adjust to match how you work):

# Shorter credential cache (minutes). Default is often 15.
Defaults        timestamp_timeout=5

# Keep sudo from accepting a bunch of environment variables.
Defaults        env_reset

# Require a TTY (helps against some non-interactive misuse). If you run automation, skip this.
Defaults        requiretty

# Use a predictable PATH for root commands.
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Two common pitfalls:

  • requiretty can break automation (cron jobs, deployment scripts). If you deploy via CI or provisioning tools, omit it.
  • timestamp_timeout that’s too low gets annoying fast; too high increases risk on shared screens.

Add an audit trail: log sudo commands and (optionally) I/O

On hosting servers, “who ran what as root” matters.

Sudo can log every command.

You can also enable I/O logging, which records terminal input/output.

That helps investigations, but it can chew disk space. Enable it intentionally.

visudo -f /etc/sudoers.d/30-sudo-logging

Add:

# Log all sudo usage to syslog/journal
Defaults        log_host, log_year
Defaults        logfile="/var/log/sudo.log"

# Optional: I/O logging (more forensic value, more storage)
Defaults        iolog_dir="/var/log/sudo-io"
Defaults        log_input, log_output

Create directories and lock permissions:

install -d -m 0700 /var/log/sudo-io
touch /var/log/sudo.log && chmod 0600 /var/log/sudo.log

Quick test:

sudo id
tail -n 20 /var/log/sudo.log

If you centralize logs (recommended for incident response), ship these logs too.

The workflow in HostMyCode’s log shipping tutorial fits well here because it covers SSH and system logs alongside web logs.

Give limited sudo access to a “webops” role (without full root)

Not every staff member needs full sudo.

A common approach is a limited role that can restart web services and read logs.

It should not install packages or edit arbitrary files.

Create a group and add users:

groupadd webops
usermod -aG webops devsam

Define allowed commands in a dedicated sudoers file:

visudo -f /etc/sudoers.d/40-webops

Example policy for Nginx/Apache/PHP-FPM on Ubuntu:

# Let webops restart services and inspect status/logs
Cmnd_Alias WEB_SVC = /bin/systemctl restart nginx, /bin/systemctl reload nginx, /bin/systemctl status nginx,
                   /bin/systemctl restart apache2, /bin/systemctl reload apache2, /bin/systemctl status apache2,
                   /bin/systemctl restart php8.3-fpm, /bin/systemctl reload php8.3-fpm, /bin/systemctl status php8.3-fpm

Cmnd_Alias WEB_LOGS = /usr/bin/journalctl -u nginx, /usr/bin/journalctl -u apache2, /usr/bin/journalctl -u php8.3-fpm,
                    /usr/bin/tail -n * /var/log/nginx/*, /usr/bin/tail -n * /var/log/apache2/*

%webops ALL=(root) NOPASSWD: WEB_SVC, WEB_LOGS

Why the command list is explicit: sudo isn’t a permission system for “folders.”

It controls which exact commands a user may run as another user.

Keep the allow-list tight, use full paths, and treat wildcards as dangerous unless you’ve tested them hard.

Control “NOPASSWD” before it controls you

NOPASSWD saves time, but it also lowers the bar for privilege escalation if an account is compromised.

Reserve it for narrowly scoped command aliases (like service reloads).

Avoid granting it to broad admin groups.

If you need passwordless sudo for automation, use a separate service account with a short, specific allow-list.

Don’t widen human access just to make scripts convenient.

Harden the sudo surface: restrict su, lock down root password behavior

On multi-user servers, su can become the side door that ignores your sudo rules.

Decide whether you want it available.

If you keep it, decide who can use it.

  • On Ubuntu/Debian, you can restrict su via PAM and group membership.
  • On many systems, limiting su to members of a specific group reduces surprises.

Example: require membership in group sudo to use su. Edit /etc/pam.d/su:

# Enable this line (uncomment) to restrict su:
auth       required   pam_wheel.so group=sudo

Test carefully from a non-root shell.

Keep your open root session until you confirm the behavior you want.

Verify the policy with a practical checklist

Run these as your admin user (opsmia) and as a limited user (in webops).

You’re checking that admin elevation works and that the limits actually hold.

  • Admin user can elevate: sudo -l, sudo apt-get update, sudo systemctl restart nginx
  • Admin user logs are written: tail -n 50 /var/log/sudo.log
  • Limited user can only run allowed commands: sudo -l and attempt a blocked command like sudo apt-get update (should fail)
  • SSH root is blocked (if configured): attempt root SSH login from a separate terminal (should fail)
  • Recovery path exists: confirm provider console access works

Common troubleshooting (real errors you’ll see)

“user is not in the sudoers file”

  • Confirm group membership: id username
  • On Ubuntu/Debian: ensure user is in sudo: usermod -aG sudo username
  • Confirm sudoers drop-in file mode is 0440: stat /etc/sudoers.d/10-ops-admin

“sudo: /etc/sudoers is world writable” or “ignored file in /etc/sudoers.d”

  • Sudo refuses unsafe permissions. Fix with: chmod 440 /etc/sudoers and chmod 440 /etc/sudoers.d/*
  • Ensure ownership is root:root.

“sudo: no tty present and no askpass program specified”

  • This usually shows up in non-interactive runs (scripts, remote commands).
  • If you enabled requiretty, remove it for automation use cases.

Locked out after SSH changes

If a firewall or SSH config change blocks access, use the provider console to roll back.

HostMyCode’s firewall troubleshooting tutorial is a practical runbook for regaining access without making the situation worse.

Team-ready pattern: break-glass admin and day-to-day admin

For reseller hosting, agencies, and businesses with staff turnover, split access so emergencies don’t become daily habits:

  • Break-glass account: very strong password, MFA at the provider console if available, used only for emergencies. Keep it out of daily SSH usage.
  • Named admin accounts: one per person. Easy to disable when roles change.
  • Limited groups: e.g., webops, support, deploy with tight sudo command aliases.

This structure keeps incident response cleaner.

You can map actions to people, not “someone used root.”

For a full containment flow after suspicious sudo usage, see VPS incident response.

Where this fits in a real hosting stack (WordPress, mail, and panels)

On WordPress VPS setups, your admin user typically handles OS updates, web services, TLS renewals, and malware response.

WordPress admins manage the CMS itself. That split is cleaner than handing CMS maintainers root access.

On cPanel/WHM servers, you’ll still use sudo (or root) for system-level tasks.

The goal is controlled, auditable access.

If you manage cPanel, pair this with a cPanel security audit checklist so OS-level and panel-level controls line up.

Summary: a safer admin workflow you can keep long-term

You now have a non-root admin account, sudo policies managed under /etc/sudoers.d/, tighter defaults, and an audit trail you can actually use.

It’s a real security win without slowing down normal server work.

If you’re rebuilding access controls during a migration—or you want a clean baseline for new servers—start on a VPS where you control the full stack.

HostMyCode VPS plans fit hands-on administration, and managed VPS hosting is there when you’d rather offload routine hardening and monitoring while keeping control of your apps.

If you’re standardizing admin access across multiple sites, build it on infrastructure that won’t box you in later. HostMyCode offers VPS hosting for full control, and managed VPS hosting when you want a hardened baseline with less day-to-day upkeep.

FAQ

Should I disable the root account?

Usually no. Disable root SSH login, but keep root available via console and via sudo for recovery.

Removing root entirely tends to complicate break-glass procedures.

Is it safe to use NOPASSWD for sudo?

It can be reasonable for a small, controlled command set (service reloads, status checks).

Avoid giving NOPASSWD to broad admin access or to users who browse the web from the same machine.

What’s the difference between adding a user to the sudo group and writing a sudoers file?

Adding a user to sudo grants whatever the group is allowed to do in sudoers.

A sudoers file gives you precise control, including limited command aliases and logging defaults.

How do I roll back if I break sudoers?

Use your still-open root session or provider console to fix /etc/sudoers or the offending file in /etc/sudoers.d/.

Then run visudo -c to validate syntax before reconnecting.

Can I use this approach on a dedicated server too?

Yes. The risk profile is similar, and dedicated servers often have more staff touching them over time.

Sudo auditing and named accounts help keep change history clear.