Configure User Accounts and Sudo Privileges in Linux

CompTIABeginner
Practice Now

Introduction

In this lab, you will learn essential techniques for managing user accounts and sudo privileges to enhance the security of a Linux system. You will practice enforcing password policies, locking and unlocking user accounts, securing the root account, and granting administrative permissions. These skills are fundamental for any system administrator responsible for maintaining a secure and well-managed Linux environment.

You will begin by using the chage command to set password expiration rules and the passwd command to control account access. Next, you will secure the system by disabling direct SSH login for the root user. Finally, you will explore two methods for granting elevated privileges: adding a user to the wheel group for general sudo access and creating custom, fine-grained rules using the visudo command to delegate specific administrative tasks safely.

Manage User Password Policies with chage

In this step, you will learn how to manage user password policies using the chage command. Enforcing password policies, such as setting an expiration date, is a crucial security practice to protect user accounts from unauthorized access. The chage command (short for "change age") allows you to view and modify password aging information for user accounts.

First, let's create a new user to safely practice on. We'll name this user testuser. Run the following command to add the user:

sudo useradd -m testuser

Next, set a password for testuser. You will be prompted to enter and confirm a new password. For simplicity in this lab, use password as the password.

sudo passwd testuser

You will see output confirming the password has been updated successfully.

New password:
Retype new password:
passwd: password updated successfully

Now that we have our testuser, let's view its default password aging settings. Use the chage command with the -l (list) option:

sudo chage -l testuser

The output shows the current policy. By default, most settings are inactive, and the password never expires.

Last password change     : <date>
Password expires     : never
Password inactive     : never
Account expires      : never
Minimum number of days between password change  : 0
Maximum number of days between password change  : 99999
Number of days of warning before password expires : 7

Let's enforce a stricter policy. We will configure the account so that:

  • -m 7: The user must wait at least 7 days before changing their password again.
  • -M 90: The password will expire after 90 days.
  • -W 14: The user will receive a warning 14 days before the password expires.

You can apply all these settings with a single chage command:

sudo chage -m 7 -M 90 -W 14 testuser

Now, verify that the changes have been applied by listing the settings again:

sudo chage -l testuser

The output should now reflect the new policy you just set.

Last password change     : <date>
Password expires     : <date + 90 days>
Password inactive     : never
Account expires      : never
Minimum number of days between password change  : 7
Maximum number of days between password change  : 90
Number of days of warning before password expires : 14

Another useful command to quickly check a user's password status is passwd -S. Let's try it on testuser:

sudo passwd -S testuser

The output provides a compact summary of the password status, including the last change date, minimum age, maximum age, and warning period.

testuser PS <date> 7 90 14 -1

You have now successfully configured and verified password aging policies for a user account.

Lock and Unlock a User Account with passwd

In this step, you will learn how to temporarily lock and unlock user accounts. This is a common administrative task, for instance, when an employee goes on a long vacation or if an account is suspected of being compromised. Locking an account prevents logins but preserves the user's data and configuration. We will use the testuser account created in the previous step.

First, let's lock the testuser account. The passwd command with the -l (lock) option is used for this purpose.

sudo passwd -l testuser

You should see a confirmation message:

passwd: password expiry information changed.

To verify that the account is locked, you can check its status with the passwd -S command again.

sudo passwd -S testuser

Notice the status field in the output. It should now start with L (Locked), indicating that password-based login is disabled.

testuser L <date> 7 90 14 -1

Let's try to switch to the testuser account to confirm it's inaccessible. Use the su (substitute user) command. You will be prompted for testuser's password.

su - testuser

Enter the password password. The login attempt will fail, which is the expected behavior for a locked account.

Password:
su: Authentication failure

Now, let's unlock the account. This is done with the passwd -u (unlock) option.

sudo passwd -u testuser

Again, you will see a confirmation message:

passwd: password expiry information changed.

Let's verify the unlocked status with passwd -S:

sudo passwd -S testuser

The status should now be PS (Password Set), indicating the account is active and has a valid password.

testuser PS <date> 7 90 14 -1

Finally, let's try to switch to the testuser account again.

su - testuser

Enter the password password when prompted. This time, the login should succeed, and your command prompt will change to show that you are now logged in as testuser.

Password:
testuser@<hostname>:~$

To return to your original labex user session, simply type exit and press Enter.

exit

You have now successfully practiced locking and unlocking a user account.

Secure the Root Account by Disabling SSH Login

In this step, you will enhance your system's security by disabling direct SSH login for the root user. Allowing remote root login is a significant security risk because it provides a direct, high-privilege target for attackers. The best practice is to log in as a standard user and then use sudo to perform administrative tasks.

First, you need to edit the SSH daemon's configuration file, which is located at /etc/ssh/sshd_config. We will use the nano text editor to modify this file. Since it's a protected system file, you must use sudo.

sudo nano /etc/ssh/sshd_config

Inside the nano editor, you need to find the line containing PermitRootLogin. You can use the search function by pressing Ctrl+W, typing PermitRootLogin, and pressing Enter.

Note: On some operating systems or in certain browser environments, the Ctrl+W shortcut may conflict with browser shortcuts. If you cannot use Ctrl+W to search, you can manually scroll through the file to locate the PermitRootLogin line, which is typically found in the authentication section of the configuration file.

You will likely find a line that looks like this:

#PermitRootLogin prohibit-password

Or it might be set to yes. Your task is to change this line to PermitRootLogin no. Make sure to remove the # at the beginning of the line if it exists, as this character comments out the line, making it inactive. The final line should look exactly like this:

PermitRootLogin no

After making the change, save the file and exit nano. Press Ctrl+X, then press Y to confirm you want to save the changes, and finally, press Enter to confirm the filename.

For the new configuration to take effect, you must restart the SSH service. Use service to do this:

sudo service ssh restart

The command will not produce any output if it executes successfully. To be sure the service is running correctly, you can check its status:

sudo service ssh status

You should see that the service is running.

Now, let's test if the change works. We will try to SSH into the machine as root from the machine itself (using localhost). First, you need to set a password for the root user to make the test valid. Use password as the password.

sudo passwd root
New password:
Retype new password:
passwd: password updated successfully

Now, attempt to SSH as root:

ssh root@localhost

The connection should be immediately rejected with a "Permission denied" error. This confirms that your security enhancement is working correctly.

root@localhost: Permission denied (publickey,password).

You have successfully secured your system by disabling direct root login via SSH.

Grant Sudo Access via the wheel Group

In this step, you will learn a standard method for granting administrative privileges: adding a user to a special group (commonly wheel or sudo) that is pre-configured to have sudo access. This approach is more manageable and scalable than adding individual user entries to the sudoers file. We will continue using the testuser account.

First, let's confirm that testuser does not currently have sudo privileges. Switch to the testuser account. The password is password.

su - testuser

Now, as testuser, try to run a command that requires root privileges, such as whoami with sudo. You will be prompted for testuser's password.

sudo whoami

After entering the password, the command will fail. You will see a message indicating that testuser is not in the sudoers file. This is the expected outcome.

[sudo] password for testuser:
testuser is not in the sudoers file.  This incident will be reported.

Now, type exit to return to your labex user session.

exit

Next, we need to edit the sudoers configuration to grant sudo access to all members of the wheel group. The safest way to edit this configuration is with the visudo command, which validates the syntax before saving to prevent you from getting locked out of the system.

sudo visudo

This will open the /etc/sudoers file in a text editor (likely vi or nano). Look for a line that refers to the %wheel group. It will probably be commented out with a # character.

## %wheel ALL=(ALL) ALL

or

## %wheel ALL=(ALL:ALL) ALL

You need to uncomment this line by deleting the # at the beginning. The result should look like this:

%wheel ALL=(ALL) ALL

If you are in the vi editor, use the arrow keys to navigate to the #, press x to delete it, and then type :wq and press Enter to save and quit. If you are in nano, simply delete the #, press Ctrl+X, then Y, and then Enter.

Now that the wheel group is empowered, add testuser to it. Use the usermod command with the -aG options, where -a means append and -G specifies the supplementary group.

sudo usermod -aG wheel testuser

To verify that testuser is now a member of the wheel group, use the groups command:

groups testuser

The output should show wheel in the list of groups for testuser.

testuser : testuser wheel

Finally, let's test if the new permissions work. Switch back to testuser.

su - testuser

Try the sudo command again. Enter password when prompted.

sudo whoami

This time, the command should execute successfully and output root, confirming that testuser now has sudo privileges.

[sudo] password for testuser:
root

Type exit to return to your labex session. You have successfully granted sudo access by adding a user to the wheel group.

Create Custom Sudo Rules with visudo

In this step, you will move beyond broad, group-based permissions and learn how to create fine-grained sudo rules. This is essential for implementing the principle of least privilege, where users are only granted the exact permissions they need to perform their duties. We will use aliases within the sudoers file to define a set of users and a set of commands, and then link them together in a rule.

First, let's create a situation to test our rule. We will start a process as the root user. The top command, a simple process monitor, is perfect for this. We'll run it in the background using sudo. Before starting, let's make sure no other top processes are running.

pgrep top || echo "No top processes running"
sudo top &

You will see the process ID (PID) of the background job. Press Enter if your prompt doesn't reappear immediately.

[1] <PID>

Now, let's create the custom rule. We will grant our testuser the specific ability to terminate processes using the kill and pkill commands. Open the sudoers file for editing using the visudo command. This is the only safe way to edit this file.

sudo visudo

This will open /etc/sudoers in an editor. Go to the end of the file. Add the following lines to define a command alias and a user alias, and then create the rule that connects them.

## Custom rule for junior administrators
Cmnd_Alias      KILL_CMDS = /usr/bin/kill, /usr/bin/pkill
User_Alias      JUNIOR_ADMINS = testuser

JUNIOR_ADMINS   ALL=(ALL) KILL_CMDS

Let's break down these lines:

  • Cmnd_Alias: Creates a named list of commands. We named ours KILL_CMDS. Note that you must use the full path to the commands.
  • User_Alias: Creates a named list of users. We named ours JUNIOR_ADMINS.
  • The final line is the rule itself. It grants the users in JUNIOR_ADMINS permission to run the commands in KILL_CMDS on all hosts (ALL).

After adding the lines, save the file and exit the editor.

To properly test this specific rule, we must first remove testuser from the wheel group to revoke the full sudo access granted in the previous step. This ensures our test is valid.

sudo gpasswd -d testuser wheel

You will see a confirmation message:

Removing user testuser from group wheel

Now, let's test the new, limited permissions. Switch to the testuser account. The password is password.

su - testuser

First, confirm that full sudo access is gone. Try to run a command that is not in our KILL_CMDS alias, like whoami.

sudo whoami

This attempt should fail with a message indicating that testuser is not allowed to execute this command.

[sudo] password for testuser:
Sorry, user testuser is not allowed to execute '/usr/bin/whoami' as root on <hostname>.

Next, try one of the permitted commands. Let's use pkill to stop the top process we started earlier. We'll use pkill -u root top to specifically target the top process running as root.

sudo pkill -u root top

This command should execute successfully without any error message. To confirm the top process has been terminated, exit back to your labex user and check for the process.

exit

Now, check if the top process is still running.

pgrep -u root top

The command should produce no output, confirming the process was successfully killed by testuser. You have now successfully created and tested a granular sudo rule.

Summary

In this lab, you learned essential techniques for managing user accounts and their security policies in a Linux environment. You practiced using the chage command to enforce password aging rules, such as setting minimum and maximum password lifetimes and warning periods. You also learned how to lock and unlock user accounts using the passwd command to control login access. To enhance system security, you modified the SSH daemon configuration to disable direct root login, a critical best practice for protecting the system's most privileged account.

Furthermore, you explored methods for delegating administrative privileges securely using sudo. You learned the standard practice of granting full sudo access by adding a user to the wheel group with the usermod command. For more granular control, you used the visudo command to safely edit the sudoers file, creating custom rules that allow specific users to execute designated commands with elevated privileges without needing the root password. This approach allows for the principle of least privilege, granting users only the permissions they need to perform their tasks.