Create a sudo user on Ubuntu, Debian and Rocky Linux — and fix 'is not in the sudoers file'

Short answer: create the user with adduser alice, add it to the admin group (sudo on Debian and Ubuntu, wheel on Rocky Linux and CentOS Stream), then log in again as that user and run sudo whoami. When it prints root, the user has sudo. Keep your root session open until that test passes.

adduser alice                 # asks for a password, creates /home/alice
usermod -aG sudo alice

# test in a second terminal or session
su - alice
sudo whoami                   # prints: root

useradd -m alice              # adduser is only an alias for useradd here
passwd alice                  # without this the account has no password
usermod -aG wheel alice

su - alice
sudo whoami                   # prints: root

Should I use adduser or useradd?

On Debian and Ubuntu, use adduser. It is a friendly wrapper that creates the home directory, copies the default shell files from /etc/skel, sets /bin/bash as the shell and asks for a password. The questions for full name, room number and phone are optional; press Enter to skip them.

useradd is the low-level tool that exists on every distribution. On Debian and Ubuntu it does surprisingly little by default: no home directory, /bin/sh as the shell and no password. Spell everything out:

useradd -m -s /bin/bash alice     # -m creates /home/alice, -s sets the shell
passwd alice

On Rocky Linux and CentOS Stream, adduser is a symlink to useradd, and the home directory and bash are the defaults there. What catches people out is the password: neither command asks for one, so run passwd alice or add an SSH key before you try to log in.

How do I give a user sudo rights?

The standard way is group membership. Both families ship a sudoers rule that gives one group full sudo rights: %sudo ALL=(ALL:ALL) ALL on Debian and Ubuntu, %wheel ALL=(ALL) ALL on Rocky and CentOS Stream. Adding a user to that group is all it takes:

sudo usermod -aG sudo alice      # Debian, Ubuntu
sudo usermod -aG wheel alice     # Rocky Linux, CentOS Stream

# equivalent alternatives
sudo gpasswd -a alice sudo
sudo adduser alice sudo          # Debian, Ubuntu only

The alternative is a rule file of its own in /etc/sudoers.d/. It suits configuration management, where one file per user is easy to add and remove, and it is the place for narrower rules. Always create it through visudo:

sudo visudo -f /etc/sudoers.d/alice
# file content, one line:
alice ALL=(ALL:ALL) ALL

sudo chmod 0440 /etc/sudoers.d/alice
sudo visudo -c                    # checks every sudoers file

sudo ignores files in that directory whose name contains a dot or ends in ~, so alice works and alice.conf silently does nothing.

How do I fix “alice is not in the sudoers file”?

The message means sudo found no rule that lets this user run commands. Older sudo versions print alice is not in the sudoers file. This incident will be reported. Newer ones, such as the one in Debian 12, put the second sentence on its own line and word it This incident has been reported to the administrator. The fix is the same either way: become root by another route and add the user to the group.

su -                          # needs the root password; note the dash
usermod -aG sudo alice        # wheel on Rocky / CentOS Stream
exit

# alice must now log out completely and log back in, then:
id                            # the group list should now include sudo (or wheel)
sudo whoami

• No root password, or root login is off? Use your provider’s console, which logs you in on the machine directly without SSH, or boot its rescue system.
• usermod: command not found after su? You used su without the dash. On Debian, that keeps your user’s PATH, which lacks /usr/sbin. Use su -.
• Added to the group, still refused? The session predates the change. Log out and in again; for SSH that means a new connection, not a new tab on a multiplexed one. id alice shows the stored membership, while plain id shows what the current session has.
• In the group and freshly logged in, still refused? The group rule may be missing or commented out. Check with sudo grep -E '^%(sudo|wheel)' /etc/sudoers as root.
• sudo: command not found instead? Minimal Debian installs can lack sudo entirely. Install it as root first, as described in sudo: command not found.

Where is “the incident” reported?

To the system log, not to anyone in particular. sudo writes every refused attempt to the auth log:

sudo journalctl -t sudo --since today     # any systemd distribution
sudo grep sudo /var/log/auth.log          # Debian/Ubuntu with rsyslog
sudo grep sudo /var/log/secure            # Rocky, CentOS Stream

# a refused attempt looks like:
# alice : user NOT in sudoers ; TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/apt update

By default sudo also tries to e-mail root about it. That mail only reaches a person if the server has a mail system installed and root’s mail is forwarded to an address someone reads, which on a fresh VPS is rarely the case.

Can I allow sudo without a password?

Yes, with NOPASSWD. Limit it to the specific commands that need it, such as a deploy script or a service restart, rather than everything:

# only this command, without a password
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp.service

# everything without a password (think twice)
alice ALL=(ALL:ALL) NOPASSWD: ALL

The trade-off: with key-only SSH, the sudo password is the one thing between a stolen key and root. NOPASSWD: ALL removes it. Many cloud images set it for their default user for convenience, but that does not make it a good default for yours. Narrow rules need care too: a command that can open a shell or edit arbitrary files, such as vim, less or tar, is effectively full root.

Why do I have to edit sudoers with visudo?

Because one syntax error in /etc/sudoers or any file in /etc/sudoers.d/ breaks sudo for every user. sudo refuses to run at all with sudo: parse error in /etc/sudoers.d/alice and no valid sudoers sources found, quitting. visudo checks the syntax before it saves, and on an error it asks What now?. Press e to fix it or x to discard the change, never Q. To use nano instead of vi, run sudo EDITOR=nano visudo.

If a broken file is already in place, you need root without sudo: su - if root has a password, otherwise the provider’s console or rescue system.

# as root on the running system
visudo -c                       # names the broken file and line
visudo -f /etc/sudoers.d/alice  # fix it, or simply delete the drop-in

# from a rescue system: mount the server's disk first (lsblk shows the device)
mount /dev/vda1 /mnt
chroot /mnt visudo -c

How do I log in as the new user with an SSH key?

If password logins are still allowed, copy your key from your own computer with ssh-copy-id. If the server is already key-only, copy root’s authorized keys across instead, with the permissions sshd insists on: 700 for the directory and 600 for the file.

ssh-copy-id alice@203.0.113.10

install -d -m 700 -o alice -g alice /home/alice/.ssh
install -m 600 -o alice -g alice /root/.ssh/authorized_keys /home/alice/.ssh/authorized_keys
restorecon -R /home/alice/.ssh    # Rocky / CentOS Stream: reset SELinux labels

Test ssh alice@203.0.113.10 and sudo whoami in a new terminal. Only then turn off root login:

echo 'PermitRootLogin no' | sudo tee /etc/ssh/sshd_config.d/10-no-root.conf
sudo sshd -t && sudo sshd -T | grep -i permitrootlogin    # should print: permitrootlogin no
sudo systemctl restart ssh        # sshd on Rocky / CentOS Stream

sshd uses the first value it reads, and the files in sshd_config.d are read before the rest of the main config, which is why a low number in the file name wins. If sshd -T still shows yes, your sshd_config has no Include line for that directory (CentOS Stream 8 is one example); set PermitRootLogin no in /etc/ssh/sshd_config itself. If the key is refused, see Permission denied (publickey); the remaining hardening steps are in securing SSH access.

How do I remove sudo rights or delete the user?

sudo gpasswd -d alice sudo        # wheel on Rocky / CentOS Stream
sudo rm -f /etc/sudoers.d/alice   # if you created a drop-in

sudo loginctl terminate-user alice    # end running sessions first
sudo deluser --remove-home alice      # Debian, Ubuntu
sudo userdel -r alice                 # any distribution

userdel refuses to remove a user who still has running processes, which is why the sessions go first. Removing the home directory deletes the user’s files and SSH keys with it, so copy anything you need beforehand. To check who still has sudo afterwards, getent group sudo (or wheel) lists the members; listing users and groups covers the rest.

On a new VMHeaven server with Ubuntu, Debian, CentOS Stream or Rocky Linux you log in as root with the password you set when ordering, so this is usually the first thing to do on a fresh Ubuntu VPS, Debian VPS or other KVM VPS. If a sudoers edit goes wrong, the VNC console in the panel still gets you in as root. The rest of the first-login checklist is in initial server setup.

Frequently asked