Security

User and Sudo Permissions Management on Linux VPS

BM BizMaC Team Jul 26, 2026 8 min read

The first thing I do on any fresh VPS is create a non-root user and hand it the right sudo privileges. Running everything as root is a one-way ticket to regret, one mistyped rm -rf or a compromised SSH session wipes the box. This guide covers adding users, assigning sudo groups, locking down sudoers with visudo, and auditing privileges. It works on Ubuntu 24.04 LTS, Debian 12, and AlmaLinux 9.

Prerequisites

  • A Linux VPS running Ubuntu 24.04, Debian 12, or AlmaLinux 9. If renting a Linux VPS, you get full root access, this guide assumes you start as root.
  • SSH access. If this is your first connection, see how to connect via SSH.
  • No existing user besides root (this is a fresh-install scenario).

Why You Are Safer With a Non-Root User

Logging in as root for daily tasks is insecure by design. The root account has unrestricted privileges, any shell command has the power to delete system files, change network config, or drop the firewall. Attackers targeting SSH brute-force attempts know the username "root" exists on every box, so they hammer it first. Even if you use a strong password, a key-based root session leaks that privilege to every command you run.

A non-root user with sudo access creates a clear boundary: you authenticate as a restricted user, then elevate only for specific commands. Sudo logs every escalation to /var/log/auth.log (or /var/log/secure on RHEL-family), giving you an audit trail. If an attacker compromises the user session, they still need to break sudo, a separate line of defense. For a low-RAM VPS with limited monitoring, this separation is your first security layer.

Step 1, Create a New User

Log in as root via SSH. The first command adds a user named deploy, you can choose any name.

On Ubuntu 24.04 / Debian 12: Use adduser, which creates the home directory, shell, and prompts for a password interactively.

adduser deploy

Set a strong password (at least 12 characters, mixed case, numbers, symbols). Fill the optional fields or press Enter to skip them.

On AlmaLinux 9 / Rocky Linux 9: Use useradd with the -m flag to create a home directory, then set the password separately.

useradd -m deploy
passwd deploy

Verify: The user exists and has a home directory.

getent passwd deploy
ls -ld /home/deploy

Expected output: deploy:x:1001:1001::/home/deploy:/bin/bash and /home/deploy present.

Step 2, Grant Sudo Privileges

On Debian-family distributions, the sudo group has full sudo rights by default. On RHEL-family, it is the wheel group. Add your user to the correct group.

Ubuntu / Debian:

usermod -aG sudo deploy

The -a (append) flag ensures you do not remove existing group memberships. sudo is the group name. On older Debian releases it may be groupname sudo, but on Debian 12 it is sudo.

AlmaLinux / Rocky / CentOS Stream:

usermod -aG wheel deploy

Now log out as root and test the new user.

exit  # back to local shell
ssh deploy@your-server-ip

Run a command with sudo:

sudo whoami

It should output root. You are now running as a non-root user who can escalate.

Step 3, Harden sudo With visudo

The file /etc/sudoers controls who can run what with which restrictions. Never edit it manually with a plain text editor, use visudo which validates syntax before saving. A broken sudoers file locks you out of sudo entirely.

Run sudo visudo as your user. On Ubuntu/Debian it opens with nano, on AlmaLinux with vi. I prefer to set the editor explicitly:

sudo EDITOR=nano visudo

Here are three hardening changes every VPS should have. Add or uncomment them in the sudoers file.

2.1, Require a Password for sudo (Default, Already Set)

By default, sudo prompts for your password. This is good, it prevents a session hijack from running sudo silently. The default line reads:

%sudo   ALL=(ALL:ALL) ALL

This means: members of the sudo group can run any command on any host as any user, but must authenticate. Keep this line. If you ever consider NOPASSWD for the whole sudo group, don't. It defeats the purpose.

2.2, Limit Which Commands a User Can Run (Optional, Strict)

If you want to restrict a user to only a handful of commands, create a separate entry. For example, allow user deploy to restart a web service and view logs, but nothing else:

deploy ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/journalctl -u nginx

This user cannot run sudo bash, sudo rm, or any command not in the list. Multi-line entries with \ are valid but ugly, keep it simple with one command per line.

Verify: As user deploy, try running a blocked command.

sudo rm /tmp/test
sudo systemctl restart nginx    # allowed

The rm command should fail with Sorry, user deploy is not allowed to execute.

2.3, Set a sudo Timeout (Tighter Window)

The default sudo credential cache is 15 minutes. Within that window you do not need to re-enter your password. For a shared VPS or high-sensitivity workload, shorten it:

Defaults timestamp_timeout=5

This forces re-authentication after 5 minutes. To disable the cache entirely (re-enter password every time), set it to 0.

Step 4, Disable Root SSH Login

With a working sudo user, you can safely disable direct root SSH access. Edit /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Find the line #PermitRootLogin yes (or similar) and change it to:

PermitRootLogin no

Also ensure PasswordAuthentication is no if you use SSH keys, the hardening SSH guide covers that. Restart SSH:

sudo systemctl restart ssh

Verify: Open a separate terminal and attempt root SSH login.

ssh root@your-server-ip
# Should fail with: Permission denied (publickey,password).

Log in as your sudo user instead.

Step 5, Audit Users and sudo Access

Periodically check who has sudo rights on your VPS. A forgotten user with sudo access is a security gap.

List all users in the sudo group:

getent group sudo
# Output: sudo:x:27:deploy,alice,bob

On AlmaLinux, use wheel:

getent group wheel

List all users on the system:

cat /etc/passwd

Focus on users with a shell (/bin/bash, /bin/zsh) and a home directory. Remove unused accounts with userdel -r username.

Check sudo log for recent escalations:

sudo grep "sudo" /var/log/auth.log | tail -20   # Debian/Ubuntu
sudo grep "sudo" /var/log/secure | tail -20      # AlmaLinux

Each sudo command logged includes the user, command, and timestamp. If you see an escalation you do not recognize, investigate.

Troubleshooting

1. "User is not in the sudoers file"
If sudo fails with this message, the user is not in the correct group. Log in as root (or via console) and add them:
usermod -aG sudo username (Ubuntu/Debian) or usermod -aG wheel username (AlmaLinux). Then log out and back in.

2. "sudo: no tty present and no askpass program"
This happens when a script runs sudo without a terminal. Add Defaults:username !requiretty to sudoers to allow non-TTY sudo for that user.

3. Lost sudo access after editing sudoers
You broke the syntax. If you still have root SSH access, fix it directly: pkexec visudo (if polkit works) or boot into recovery. Prevent this by always running visudo, it catches syntax errors before saving.

FAQ

What is the difference between adduser and useradd?

adduser is a friendlier wrapper (Debian/Ubuntu) that creates the home directory, sets the shell, and prompts for a password interactively. useradd is the low-level tool on RHEL-family, it does not create a home directory unless you pass -m and does not set a password. For most cases on a modern VPS, adduser is the safer choice.

Should I use NOPASSWD for my sudo user?

Only in specific cases, automation scripts running via CI/CD or a headless server where no human types the password. For daily interactive use, keep password prompts. They add a second factor: even if your SSH key is compromised, the attacker still needs your sudo password.

How do I remove sudo access from a user?

Remove the user from the sudo or wheel group: sudo gpasswd -d username sudo (Ubuntu/Debian) or sudo gpasswd -d username wheel (AlmaLinux). The user still exists but can no longer run sudo.

What is the default sudo timeout and how do I change it?

The default timeout is 15 minutes. Add Defaults timestamp_timeout=5 via visudo to reduce it to 5 minutes. Set it to 0 for prompt-on-every-command.

Can I have multiple sudo users with different permissions?

Yes. Create separate entries in /etc/sudoers.d/ per user (e.g., /etc/sudoers.d/deploy). This is cleaner than editing the main file and keeps permissions modular. Each file follows the same syntax.

Related articles

Note: This guide is for general reference. Every system and infrastructure has its own specifics, so test each step in a safe environment and consult a qualified engineer before applying it in production.