How to Add a User to Sudoers in Ubuntu

The quick solution: adding the user to the sudo group

On Ubuntu machines, the quickest way to give sudo permissions to the user is by adding him to the sudo group:

sudo usermod -aG sudo username

This built-in group is preconfigured on Ubuntu and Debian to have full administrative rights due to /etc/sudoers configuration, so the user will be able to execute commands with root privileges after adding them to this group. In case you are familiar with RHEL, Fedora, and CentOS, it is equivalent to the wheel group—just different names for the same concept.

Importance of the -a flag

While this -a flag is quite often overlooked, using it without it is dangerous. Running

usermod -G sudo username

without -a flag removes from the user all group memberships except sudo, and thus removes the access to other groups like docker or www-data. Always use -a flag with -G option unless you wish to remove all existing group memberships.

Effecting the new access

Changing the group membership does not affect existing sessions. If the user is logged in via SSH session at the moment of the command execution, he will have to disconnect and reconnect to use the sudo command with his new group membership. Otherwise, one of the following commands in the same shell will do:

newgrp sudo
su - username

Verifying sudo access

There are several ways to make sure that the configuration is applied:

groups username
sudo -l -U username

The first command outputs all groups the user belongs to, and there should be sudo among them. The second command outputs the sudo rules the user is eligible to, and this becomes important when the action goes beyond broad group membership. And last verification step: ask the user to run sudo whoami, and in case of success, he will get root, otherwise, the error message will tell that the user is not in sudoers file.

Alternative with better control: separate file in /etc/sudoers.d/

Giving a user membership in the sudo group grants him full root access, and while it is okay for personal server usage, it is often too much access for shared environments. Using a separate file in /etc/sudoers.d/ allows precise specifying of what actions are allowed to the user while keeping this rule separated from other users' configurations:

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

One of the possible lines allowing full access will be

username ALL=(ALL:ALL) ALL

Or in case you want to allow some specific action without password,

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

In both cases, the file must belong to the root user and must have 0440 permissions, otherwise, sudo will refuse to parse this file. Debian's own package-linting rules flag this explicitly: files in /etc/sudoers.d/ should have 0440 permissions to be parsed by sudo.

/etc/sudoers include /etc/sudoers.d by default and ignore all files in it with dot or tilde in the name—a nice feature, since editor-created backup files will not be considered as sudo rules.

Reasons to avoid direct edit of /etc/sudoers

Even though /etc/sudoers is a plain text file, editing it with editors like nano or vim is not recommended. visudo is designed to prevent a single typo from locking out everyone from accessing sudo commands.

According to the Debian manual for visudo, visudo edits the copy of this file, locks it from other edits, parses it, and saves if there are no errors. Otherwise, the change is not written to the file giving a user an opportunity to fix it. Editing the file manually skips all these steps and may leave the system in a state where neither the user nor root via sudo are able to execute privileged commands until fixing in a root shell or rescue environment.

Revoke sudo access

If access was granted via the sudo group, then it can be revoked the same way as it was granted:

sudo gpasswd -d username sudo

Just like with granting, the change takes effect after the next login. And in case the access was granted via sudoers.d file, the revoke will be easier—delete the file:

sudo rm /etc/sudoers.d/username

For organizational purposes, using sudoers.d files gives greater scalability since privileges of each user are isolated and deletion of a single file removes the access. The examples of such use are OrbitServers VPS instances which give full root access right from the boot.