As a systems administrator, you may want to assign limited admin privileges to a delegated administrator so they can assist with administrative tasks. To help you accomplish this, the following tutorial will examine how to create a sudo user as well as manage sudo access on Ubuntu 22.04.
What Is a Sudo User?
The root user, also known as the superuser, is the user with the highest privileges in a Linux system. The user has rights to execute virtually any command without restriction, including installing and uninstalling applications, modifying configuration files, adding and removing user accounts, upgrading the system, and creating and removing files, among other things.
However, logging in and carrying out commands as root is highly discouraged. The fact that the root user can run any command on the system can also be risky. All it takes is one bad command to be executed and the whole system can be compromised. As such, it’s always recommended to administer the Linux system as a sudo user.
In Linux, sudo is a program that allows a regular user to run commands with root privileges or permissions. Sudo stands for either “super user do” or “substitute user do.” A sudo user is a regular user that can run some commands as a root user or with root privileges.
Ideally, a sudo user is granted just enough privileges to allow them to perform the tasks at hand. This is known as the least privilege principle, which is particularly important if you are granting sudo privileges to multiple users. They should only be granted the minimum rights or permissions needed to perform their role.
How to Create a Sudo User
Now that you know why a sudo user is essential on a Linux system, let’s create and configure a sudo user on Ubuntu 22.04.
Step 1: Log in to your server
To get started, log into your Ubuntu 22.04 server instance as the root user with the following SSH command:
$ ssh root@server-ip
If you are using the Putty SSH client, simply type in your server’s IP address as indicated and click Open.
When prompted, provide the root password and hit ENTER. Once successfully logged in, you will land on the shell of your server instance.
Step 2: Create a new user
To create a sudo user, you will first create a new login user and later make the user a sudo user.
To add or create a new user, run the adduser command as follows. In this example, we are creating a new regular user called jumpcloud.
# adduser jumpcloud
The following happens when you run this command:
- A new user and group are created. The new group is referred to as the primary group and it corresponds to the name of the newly added user.
- The user is then added to the primary group.
- A home directory for the user is then created and configuration files are copied into it.
- You will then be prompted for the new user’s password. Be sure to provide a strong password and confirm it.
After providing the password, you will be prompted to provide additional information such as Full Name, Room Number, Work Phone, and Home Phone. Fill in where applicable, or simply press ENTER to leave it blank. Finally, press Y to save all the information provided.
All users’ details are stored in a special file called the /etc/passwd file. To confirm that the user was created, you can view this file using the cat command as follows:
# cat /etc/passwd | grep jumpcloud
In addition, you can get more details about the user using the id command as follows:
# id jumpcloud
The command displays the UID (User ID), GID (Group ID), and the groups that the user belongs to.
Step 3: Add the new user to the sudo group
At this point, the user belongs only to the primary group. You can confirm this by running the following command:
# groups jumpcloud
To add the user to the sudo group, use the usermod command as follows:
# usermod -aG sudo jumpcloud
Next, verify that the user now belongs to the sudo groups by running the id and groups command as shown.
# id jumpcloud
# groups jumpcloud
This time around, you will notice the user now belongs to two groups: the primary group and sudo.
Step 4: Test sudo
So far, we have created a regular user and added it to the sudo group, effectively granting it elevated privileges to run administrative tasks. Next, we are going to test its ability to execute privileged commands.
First, switch to the sudo user as follows:
# su – jumpcloud
The command switches to the sudo user’s home directory. When you switch to the sudo user for the first time, you will get a few tips on how to run commands as an administrator.
To run commands as a sudo user, use the following syntax:
$ sudo command-to-be-executed
For example, to install the Apache web server, run the command:
$ sudo apt install apache2
When prompted, type Y and hit ENTER to continue with the installation.
Examining the Sudoers File
The sudoers file is a file that exists by default in UNIX/Linux systems and is used to assign elevated privileges to users. The sudo user we have just created can run commands in the same way the root user can.
However, if you’re granting sudo privileges to multiple users and would like to limit the commands they can run as sudo, you’ll want to keep track of their permissions by making use of the sudoers file.
The sudoers file is located at /etc/sudoers. The file contains a set of rules that specify which users and groups can run certain elevated tasks on the system.
Note that directly editing the sudoers file is not recommended as it can lock you out of sudo privileges, as well as potentially destroy the system if you make a typo and end up with an incorrect username or wrong command.
Equally dangerous is losing your connection midway as you edit the sudoers file. A broken connection means that the last changes made to your disk will be saved, and these might contain broken syntax or incorrect sudo privilege definitions.
The proper way of making changes to the sudo configuration is using the visudo command.
When executed, the command opens the /etc/sudoers file using the nano editor as shown.
Most lines are commented out and have no effect on the permissions assigned to users and groups. Scroll all the way down to the section that says #User privilege specification. Under that, you will see the root user defined as follows:
root ALL=(ALL:ALL) ALL
Some important notes on understanding this line:
- The root directive stands for the root user.
- The first “ALL” indicates the rule applies to all hosts.
- The second “ALL” indicates the root user can execute all commands as all users.
- The third “ALL” indicates the root user can run all commands as all the user groups.
- The last “ALL” indicates the rules are applicable to all commands.
The following line indicates that the admin group can execute all commands as any user.
%admin ALL=(ALL) ALL
This next line shows that the sudo user can run any command as any user and as any group.
%sudo ALL=(ALL:ALL) ALL
While it is possible to edit the sudoers file directly using visudo, this is not the preferred approach. A better way of making changes to the configuration is by adding a new file containing new sudo rules in the /etc/sudoers.d directory, as described in the next section.
How to Restrict Sudo Users From Executing Certain Commands
As pointed out earlier, you can restrict sudo users from performing certain tasks on the system. Instead of directly editing the sudoers file, a better approach is to create a custom file for each user and place it in the /etc/sudoers.d directory.
To illustrate this, we are going to create a rule called jumpcloud as follows.
# vim /etc/sudoers.d/jumpcloud
We will specify two rules, one that prevents the user from upgrading packages to their latest versions and another that prevents the user from installing any packages. To accomplish this, paste the following line of code into the file:
jumpcloud ALL=!/usr/bin/apt upgrade, !/usr/bin/apt, !/usr/bin/apt install
An exclamation mark (!) precedes the full binary path of the comma-separated commands. To find the full path of a command, run the which command as follows:
$ which command
For example, to find the full binary path of the apt upgrade command, run:
$ which apt upgrade
Similarly, run the following command to find the full path of the apt install command:
$ which apt install
The !/usr/bin/apt upgrade directive prevents the user from performing the sudo apt upgrade command while the
!/usr/bin/apt, !/usr/bin/apt install directives prevent the user from installing any packages using the sudo apt install command.
With the custom rule in place, the user will not be able to upgrade system packages or install any software packages as demonstrated below.
How to Run Specific Sudo Commands Without a Password
Password prompts are not always desirable, especially when you want to automate tasks in shell scripts or run frequently carried out tasks such as refreshing the local repositories.
As such, you might want to disable password prompts for commands that are frequently executed. To do so, use the NOPASSWD directive followed by the full path to the command.
The sudo rule entry below disables password prompts when the user updates the local repositories.
jumpcloud ALL=(ALL) NOPASSWD: /usr/bin/apt update
The sudo user can now update the repositories by running sudo apt update without being prompted for a password.
It’s always a good idea to create and run the system as sudo to avoid breaking things in the event a command is run erroneously or otherwise. It’s also highly important to assign just the right amount of privileges sudo users need to run their tasks and revoke ones they don’t need to prevent undesirable outcomes.
Managing the process to assign specific permissions to specific users can be overly time-consuming and quickly overwhelm your priorities, especially if you are facing a growing environment and a growing team.
JumpCloud’s Linux device management capabilities make it easier to manage sudo access across entire fleets through its user security settings and permissions. To see how this works, along with a number of other device security and management features, sign up for your free account today. JumpCloud is free to use for up to 10 users and 10 devices, and you’ll also receive 24×7 in-app support for the first 10 days of use.
Would you prefer tailored, white glove implementation assistance? Schedule a free 30-minute technical consultation to learn about the service offerings available to you.