How to use Sudo on Debian

Sudo runs a single command with root privileges instead of handing you a root session. Two things follow from that, and neither is true of a root shell left open in a terminal: every call is written to the system log, and the privileges can be limited per account and per command.

This guide covers how to install sudo on Debian, how to give an account the rights it needs, and how to change the configuration without locking yourself out. Version numbers refer to Debian 12 (“Bookworm”) with sudo 1.9.13p3 and Debian 13 (“Trixie”, released on 9 August 2025) with sudo 1.9.16p2; the Debian package tracker has the current figures.

Requirements for Sudo on Debian

Whether a Debian machine has sudo at all was decided during installation. The installer asks for a root password, and the answer produces two rather different systems.

Field left empty: the root account is locked, the sudo package is pulled in, and the first account created may use it. The Debian installation guide puts it like this: “In case you do not specify a password for the “root” user here, this account will be disabled but the sudo package will be installed later to enable administrative tasks to be carried out on the new system.”

Root password set: root stays usable, sudo may be missing entirely, and every further account is created without sudo rights. That second case is what the rest of this guide is about.

One harmless call answers whether the package is already there:

sudo --version | head -n 1

If the shell replies with sudo: command not found, the package is missing. Installing it needs a root shell, because the tool that would normally provide one is exactly what is absent:

su -

If the root password is unknown as well, only a rescue system or single-user mode will help. Everything below assumes a root shell is within reach.

Installing the Sudo package and enabling an account

Three steps as root are enough.

1. Refresh the package lists:

apt update

2. Install the package:

apt install sudo -y

3. Add the account to the sudo group. Debian’s stock configuration grants every member of that group full rights. Replace Username with the account name:

usermod -aG sudo Username

The -a matters more than it looks. Without it, usermod -G replaces the supplementary groups rather than adding one, and the manual page says so plainly. A forgotten -a therefore drops the account out of every group it belonged to. Debian’s own adduser avoids the trap because it takes the group as a second argument:

adduser user sudo

Group membership only takes effect after a new login

This is where setups fail most often: the account is in the group and sudo still refuses. Sudo is not the culprit. A process gets its supplementary groups when the session starts, and child processes merely inherit them (credentials(7)). A shell that was already open never learns about the new group.

Logging out and back in fixes it. For a quick test any fresh login shell will do, via su - or a new SSH session. newgrp sudo also sets the group, but only for the shell that calls it (newgrp(1)).

su - Username
sudo -v

sudo -v only answers whether the call is permitted at all, and refreshes the cached credentials while doing so. That cache defaults to 15 minutes according to sudoers(5), and sudo -k discards it straight away. For the actual permissions, use sudo -l:

sudo -l

The output lists every rule that applies to the calling account on this host (sudo(8)). An empty list means either the group has not taken effect yet or no rule matches. id shows which groups the running session actually carries.

Granting narrower rights: the sudoers file

The sudo group knows two states, all or nothing. Allowing an account exactly one command and nothing else means editing the configuration.

And that is never done with an ordinary editor. visudo locks the file against simultaneous edits and checks it for syntax errors before installing it (visudo(8)). A typo in /etc/sudoers otherwise breaks every sudo call on the machine, including the one you would need to repair it.

sudo visudo

A line for a single account looks like this:

Username ALL=(ALL:ALL) ALL

Read left to right, the fields are: the account, the hosts the rule applies to, then in brackets the users and groups it may act as, and finally the commands it may run. Four times ALL therefore grants precisely what group membership grants.

Custom rules still do not belong in /etc/sudoers itself but in a file of their own next to it. sudoers(5) provides the @includedir /etc/sudoers.d directive for that: sudo reads every file in the directory but skips names containing a dot or ending in a tilde, so package manager backups cannot activate rules by accident. Give the file a name without an extension. visudo edits such files only when told to:

sudo visudo -f /etc/sudoers.d/maintenance

Its content, for example:

maintenance ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

The maintenance account may now run that one command, and it may do so without being asked for a password. NOPASSWD is convenient and gives away the very protection sudo provides: whoever takes over the session gets the command for free. For scripts and cron jobs the entry makes sense, for an account a human logs into it rarely does.

Whether the configuration as a whole parses is answered by a call that changes nothing:

sudo visudo -c

Sudo records every invocation, the successful ones and the rejected ones alike. Where those records end up has changed: since Debian 12 rsyslog is no longer part of a default installation, so /var/log/auth.log may simply not exist on a freshly installed machine (Bookworm release notes, section 5.1.7). Read the journal instead:

journalctl -t sudo -n 20

-t filters by the syslog identifier a service logs under (journalctl(1)). The same trail is useful for diagnostics that need root anyway, for instance when open ports and their owning process are the question.

One last snag concerns anyone working with aliases. Sudo is not a shell builtin, so the word after it is no longer expanded as an alias. Bash makes an exception when the alias value itself ends in a blank: then it checks the following word too (Bash manual). That is the whole mechanism behind the common alias sudo='sudo '.

Conclusion

Setting sudo up on Debian takes a few minutes: install the package, add the account to the sudo group, log in again. The places where it still goes wrong are always the same three. Group membership applies only to a new session. /etc/sudoers is edited with visudo and nothing else. And every NOPASSWD rule hands back the protection the switch to sudo was meant to buy. Knowing those three, you can leave the root account locked and lose nothing by it.

FAQs