Table of Contents

Introduction

When managing a server, you’ll sometimes want to allow users to execute commands as “root,” the administrator-level user. The sudo command provides system administrators with a way to grant administrator privileges — ordinarily only available to the root user — to normal users.

In this tutorial, you’ll learn how to create a new user with sudo access on Ubuntu without having to modify your server's /etc/sudoers file.

Note: If you want to configure sudo for an existing user, skip to step 3.

Also, if you are using an older version of Ubuntu, we recommend you upgrade to a more latest version since Ubuntu no longer provides support for these versions. This collection of guides will help you in upgrading your Ubuntu version.

Steps to Create a New Sudo User

  1. Log into Server
  2. Add a New User to the System
  3. Add the User to its Sudo Group
  4. Test Sudo User Access

Step 1 — Logging Into Your Server

user illustration for: Step 1 — Logging Into Your Server

SSH in to your server as the root user:

				
					[environment local]
ssh root@<^>your_server_ip_address<^>

Step 2 — Add New Sudo User to the System

Use the adduser command to add a new user to your system:

				
					adduser <^>sammy<^>

Be sure to replace <^>sammy<^> with the username that you want to create. You will be prompted to create and verify a password for the user:

				
					[secondary_label Output]
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Next, you'll be asked to fill in some information about the new user. It is fine to accept the defaults and leave this information blank:

				
					[secondary_label Output]
Changing the user information for &lt;^&gt;sammy&lt;^&gt;
Enter the new value, or press ENTER for the default

 Full Name []:

 Room Number []:

 Work Phone []:

 Home Phone []:

 Other []:

Is the information correct? [Y/n]

Step 3 — Adding the User to the sudo Group

Use the usermod command to add the user to the sudo group:

				
					usermod -aG sudo &lt;^&gt;sammy&lt;^&gt;

Again, be sure to replace <^>sammy<^> with the username you just added. By default on Ubuntu, all members of the sudo group have full sudo privileges.

Step 4 — Testing sudo Access

To test that the new sudo permissions are working, first use the su command to switch to the new user account:

				
					su - &lt;^&gt;sammy&lt;^&gt;

As the new user, verify that you can use sudo by prepending sudo to the command that you want to run with superuser privileges:

				
					sudo &lt;^&gt;command_to_run&lt;^&gt;

For example, you can list the contents of the /root directory, which is normally only accessible to the root user:

				
					sudo ls -la /root

The first time you use sudo in a session, you will be prompted for the password of that user’s account. Enter the password to proceed:

				
					[secondary_label Output:]
[sudo] password for &lt;^&gt;sammy&lt;^&gt;:

Note: This is _not_ asking for the root password! Enter the password of the sudo-enabled user you just created.

If your user is in the proper group and you entered the password correctly, the command that you issued with sudo will run with root privileges.

Understanding the Difference between sudo and su

Both sudo and su are Linux commands that allow you to execute commands with elevated privileges, but they approach this task differently.

sudo (_SuperUser Do_ _or _Substitute User Do_) lets a permitted user run a command as another user (by default, the root user) by authenticating with their own password. It's designed for executing a single command or a series of commands for a limited time, and its access is highly configurable through the /etc/sudoers file. A key benefit of sudo is that it provides a robust audit trail, logging each command executed with escalated privileges, making it a generally more secure practice for daily administrative tasks as it avoids sharing the root password directly.

On the other hand, su (_Substitute User_ or _Switch User_) allows you to completely switch to another user's account and requires the password of the target account. When you use su (especially with the – or –login option, like su -), you enter a full login session as that user, inheriting their environment variables and home directory. This grants full access to the target user's environment and privileges for the entire session until you explicitly exit. While simple for switching users, su doesn't inherently log individual commands executed within the session, and it can be less secure if the root password is widely known.

Creating Users Without Shell Access (for Automation or Service Accounts)

In many system administration scenarios, you might need to create user accounts that are not intended for interactive login by a human user but used by applications, scripts, or specific services (like an FTP server, web server, or database) to manage files, run processes, or interact with other system components. For security reasons, it's vital to prevent these accounts from being used for direct shell access.

You can create such users by specifying a "no-login" shell during the account creation process. The two most common no-login shells are /usr/sbin/nologin and /bin/false. Both effectively prevent a user from obtaining an interactive shell session upon login. Choosing either one effectively locks out interactive shell access for the user.

Using adduser to Create a No-Login User

When using adduser, you can specify the shell with the --shell option:

				
					sudo adduser --system --no-create-home --shell /usr/sbin/nologin serviceuser

Let's break down the different flags:

  • --system: This option creates a "system user." System users typically have UIDs (User IDs) below 1000 (though this range can vary), distinguishing them from regular interactive users. They are also often excluded from password expiration policies and certain system reports.
  • --no-create-home: For service accounts, a separate home directory might not be necessary, especially if the account only needs to access specific predefined directories. This option prevents adduser from creating a home directory. If the service does require a directory for its own files, omit this and specify a different home path.
  • --shell /usr/sbin/nologin: This is the crucial part. It assigns /usr/sbin/nologin as the user's default shell. When this user attempts to log in, they will typically receive a message like _"This account is currently not available"_ and the connection will be closed.

For example, to create a system user named ftpuser without a home directory and no shell access, suitable for an FTP daemon, we use the following command:

				
					sudo adduser --system --no-create-home --shell /usr/sbin/nologin ftpuser

Using useradd to Create a No-Login User

If you prefer useradd for its more direct control, you can use it to achieve the same result:

				
					sudo useradd -r -s /usr/sbin/nologin serviceuser

Let's understand the flags:

  • -r: This option creates a system account (similar to adduser --system).
  • -s /usr/sbin/nologin: Explicitly sets /usr/sbin/nologin as the user's login shell.

By default, useradd does not create a home directory unless the -m option is used. So, omitting -m will result in no home directory, which is often desired for these types of accounts.

To create a system user named db_reader with no shell access and no home directory, we can use the following command:

				
					sudo useradd -r -s /usr/sbin/nologin db_reader

Using sudo -l to List Allowed Commands

As an administrator or a regular user, it's often useful to quickly check what sudo privileges you or another user possess on a system. The sudo -l command provides this capability by listing the commands a user is allowed to execute via sudo.

To see your own sudo privileges, simply run:

				
					sudo -l

You will typically be prompted for your password. After successful authentication, sudo will display a list of rules that apply to your user account in the /etc/sudoers file or its included directories.

If you have sudo access yourself, you can use sudo -l to check the privileges of another user by specifying their username with the -U option:

				
					sudo -U another_username -l

Replace another_username with the actual username you want to check. This is an invaluable tool for administrators to audit and verify user permissions quickly without having to directly inspect the /etc/sudoers file.

Best Practices for User Permissions and Limiting sudo Commands

Let's discuss some of the best practices for managing user permissions and limiting sudo commands, crucial for maintaining a secure and robust Ubuntu system:

Best Practices for User Permissions

User permissions dictate who can read, write, or execute files and directories on your system. A strong permission strategy is built on the Principle of Least Privilege (PoLP), meaning users and processes should only have the minimum necessary access to perform their intended functions.

  • Implement the Principle of Least Privilege (PoLP): This is the golden rule. Never grant more permissions than absolutely required. If a user only needs to read a file, do not give them write or execute access.
  • Understand File and Directory Permissions: Define who can access and manipulate data on your system, categorized by owner, group, and others, using the chmod command.
  • Utilize Group Management: Instead of granting individual permissions to many users, create groups for specific functions and add relevant users to these groups. Set file and directory permissions so that the owner and the specific group have the necessary access, while others have minimal or no access.
  • Be Mindful of umask: The umask setting (usually in .bashrc or system-wide configuration) determines the default permissions for newly created files and directories. Ensure your umask is appropriately restrictive.

Limiting sudo Commands

Granting full sudo access (i.e., allowing a user to run ALL=(ALL:ALL) ALL in /etc/sudoers) is the same as giving them the root password. While convenient, it poses a significant security risk. Best practices dictate limiting sudo privileges to only what is absolutely necessary.

  • Grant Only Necessary Commands: Instead of allowing a user to run "ALL" commands, specify the exact command(s) they need.
  • Use Absolute Paths for Commands: Always specify the full, absolute path to any command listed in your sudoers file (e.g., /usr/sbin/service instead of just service). This prevents a malicious user from creating a custom executable with the same name elsewhere in the system's PATH and tricking sudo into running their malicious version.
  • **Avoid Wildcards (*) and Regular Expressions**: Using wildcards or complex regular expressions in sudoers rules can unintentionally grant broader access than intended. Be extremely cautious and ensure every command is explicitly defined if possible.
  • Be Cautious with NOPASSWD: The NOPASSWD tag allows a user to execute a sudo command without being prompted for their password. Only use NOPASSWD for commands that are genuinely harmless, non-system-altering, and frequently executed, such as status checks. For any command that involves system modification or access to sensitive data, a password should always be required.
  • Control Environment Variables: By default, sudo cleans a user's environment before executing commands to prevent privilege escalation via manipulated environment variables (like PATH). Avoid using the SETENV tag in your sudoers rules unless it is absolutely essential for a specific application's functionality, as it can introduce security vulnerabilities.

FAQs

1. What is the difference between adduser and useradd?

adduser is a high-level, and user-friendly script that simplifies the process of creating a new user account. It interactively prompts for information, automatically creates a home directory, copies skeleton files (like .bashrc, .profile), sets appropriate permissions, and assigns a default shell. In most cases, it's the recommended command for creating users on Debian-based systems like Ubuntu.

useradd is a lower-level binary that provides fine-grained control over user creation. It does not create a home directory or copy skeleton files by default, requiring these to be specified with options or handled manually. It's often used in scripts or for automated system management where precise control and non-interactive operation are necessary.

2. How do I check if a user has sudo privileges?

The simplest way to check if a user has sudo privileges is to use the getent command to inspect the /etc/group file:

				
					getent group sudo

This command will list the members of the sudo group. If the username you're checking is listed, they have sudo privileges.

Alternatively, the user can try running a command with sudo, such as:

				
					sudo ls /root

If they are able to list the contents of /root (which requires root privileges), they have sudo access. If they are not, they will be prompted for a password, and if they are not in the sudo group, the command will fail.

3. Is it safe to disable the root account after creating a sudo user?

Yes, it is generally considered safe and even a good security practice to disable the root account after creating a user with sudo privileges. Disabling direct root login reduces the attack surface of your system. Instead of logging in as root, administrators can log in with their regular user accounts and use sudo to perform administrative tasks.

You can disable the root account by locking its password:

				
					sudo passwd -l root

This prevents direct login as root. To re-enable the root account, you can unlock it:

				
					sudo passwd -u root

4. How can I give limited sudo access?

Instead of granting full sudo access (allowing a user to run any command as root), you can configure limited sudo access, allowing a user to run only specific commands as root. This is done by editing the /etc/sudoers file using the visudo command.

For example, to allow the user webadmin to restart the Apache web server:

				
					sudo visudo

Then, add a line like this:

				
					webadmin ALL=(ALL:ALL) /usr/sbin/service apache2 restart

This line specifies that the user webadmin can run the command /usr/sbin/service apache2 restart as root.

[warning]

Caution: Incorrect modifications to the /etc/sudoers file can severely impact system administration. Always be careful when using visudo.

Conclusion

In this quickstart tutorial, we created a new user account and added it to the sudo group to enable sudo access. We covered the differences between sudo and su, and learned how to create an user without shell access for service accounts. We also discussed the best practices to be followed while granting user permissions and limiting sudo commands.

For your new user to be granted external access, please follow our section on Enabling External Access for Your Regular User.

If you need more detailed information on setting up an Ubuntu server, please choose your distribution from this list to follow your specific Initial Server Setup Guide.

For more Ubuntu-related topics, you can refer to the following articles: