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+Wshortcut may conflict with browser shortcuts. If you cannot useCtrl+Wto search, you can manually scroll through the file to locate thePermitRootLoginline, 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 oursKILL_CMDS. Note that you must use the full path to the commands.User_Alias: Creates a named list of users. We named oursJUNIOR_ADMINS.- The final line is the rule itself. It grants the users in
JUNIOR_ADMINSpermission to run the commands inKILL_CMDSon 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.



