Troubleshooting Su Authentication Failures on Linux

Introduction

The "su" (substitute user) command in Linux is a powerful tool that allows users to temporarily switch to a different user account, often the root user, to perform administrative tasks. However, su authentication failures can occur, leading to access denials and potential security risks. This tutorial will guide you through the process of troubleshooting su authentication failures on Linux, covering common causes, configuration settings, and best practices for secure su usage.

Understanding the Su Command and Basic Usage

In this step, you will learn how the su command in Linux allows users to switch their current user identity to another user. This is particularly useful for performing administrative tasks that require elevated privileges.

Let us explore the basic usage of the su command and understand how it works.

Basic Usage of Su

Open a terminal in your LabEx VM environment. You can use the su command with the following syntax:

su [options] [username]

If you run su without specifying a username, it defaults to the root user:

su

The command targets root, but Ubuntu normally locks root password authentication. An authentication failure here is expected. Do not enable root password login or change the platform account; all positive login tests below use disposable lab users.

Let us create a test user to practice with:

sudo adduser testuser

Enter the required information when prompted. For this disposable test account only, use DemoUser123! as its practice password. Never change the labex password or sudo membership.

Now, let us try to switch to this user:

su testuser

When prompted, enter the password you created for testuser. Once authenticated, your prompt will change, indicating you are now operating as testuser.

To verify that you have successfully switched users, run:

whoami

The output should show:

testuser

To return to your original user, simply type:

exit

Using Su with Options

The su command supports several options. The most common is the - (hyphen) option, which provides a full login environment:

su - testuser

This not only switches the user identity but also:

• Changes to the target user's home directory
• Sets up the environment variables of the target user
• Provides a login shell

Try this command and observe the differences:

pwd

The output should show the home directory of testuser:

/home/testuser

Exit from testuser by typing:

exit

This basic understanding of the su command will help us troubleshoot authentication failures in the next steps.

Common Su Authentication Failures and Their Causes

In this step, you will create and inspect common su authentication failures. Understanding these failures is the first step toward resolving them.

Testing Authentication Failures

Let us intentionally create some authentication failures to better understand them.

First, try switching to testuser with an incorrect password:

su testuser

Enter an incorrect password. You will see an error message similar to:

su: Authentication failure

Next, try switching to a non-existent user:

su nonexistentuser

You will see an error message like:

su: user nonexistentuser does not exist

Common Causes of Authentication Failures

1. Incorrect Password

The most common cause of authentication failure is simply entering the wrong password. This can happen due to:

• Typos
• Caps Lock being enabled
• Forgetting the password

2. Account Restrictions

Some accounts might be configured to prevent login or have expired passwords:

Let us modify our test user to demonstrate this:

sudo usermod -L testuser

The -L option locks password authentication for the disposable testuser account. Now try:

su testuser

You will see an authentication failure even if you enter the correct password.

The -U option removes that password lock. Unlock only this test account with:

sudo usermod -U testuser

3. PAM Configuration Issues

The Pluggable Authentication Modules (PAM) system controls authentication in Linux. Issues with PAM configuration can cause su failures.

Let us examine the PAM configuration for the su command:

cat /etc/pam.d/su

This file contains the PAM configuration specific to the su command. Look for lines that might restrict access, such as:

auth       required   pam_wheel.so

This line, if uncommented, would restrict su access to members of the wheel group.

4. Permission Issues with the Su Binary

The su command's binary file must have the correct permissions to function properly:

ls -l $(which su)

The output should show something like:

-rwsr-xr-x 1 root root 71816 Apr 18  2022 /usr/bin/su

The s in the permissions indicates that the setuid bit is set, allowing the program to run with the privileges of its owner (root) rather than the user who runs it.

5. Examining Authentication Logs

When troubleshooting authentication failures in this LabEx VM, check failed login records with lastb:

sudo lastb | head

This command reads /var/log/btmp and displays recent failed authentication attempts, including failed su attempts when they are recorded by the system.

For example, a failed su attempt might show an entry that includes the target user and the terminal session.

Understanding these common causes of su authentication failures will help you identify and resolve issues more effectively in the next steps.

Configuring Access Control for the Su Command

In this step, you will test a PAM group rule against a disposable target account. You will not enable root password login or restrict platform access.

Prepare the Disposable Accounts

Start in your original labex shell. Confirm the current identity before using sudo:

whoami

The result must be labex. Create a second caller and a separate target, then set passwords only for those disposable accounts:

sudo adduser --disabled-password --gecos '' testuser2
sudo adduser --disabled-password --gecos '' su-lab-target
printf '%s\n' 'testuser2:DemoOther123!' 'su-lab-target:DemoTarget123!' | sudo chpasswd
sudo groupadd sugroup
sudo usermod -aG sugroup testuser

Only testuser is a member of sugroup. New login shells will pick up that membership. The target password is DemoTarget123! for both caller tests.

Apply a Target-Specific PAM Rule

PAM controls authentication for su through /etc/pam.d/su. Setup saved its original bytes under /opt/labex/su-demo. The following managed prefix applies a group check only when the target is su-lab-target. The first rule skips the next rule for every other target, including labex. use_uid checks the real identity of the caller, and group=sugroup names the permitted group.

sudo python3 - <<'PY'
from pathlib import Path
original = Path('/opt/labex/su-demo/pam-su.original').read_text()
prefix = """## Lab-only rule for su-lab-target

auth [success=1 default=ignore] pam_succeed_if.so quiet user != su-lab-target

auth required pam_wheel.so use_uid group=sugroup

"""
Path('/etc/pam.d/su').write_text(prefix + original)
PY

The original PAM rules remain after this prefix. Group membership does not replace password authentication. Do not add labex to the demonstration group or edit any SSH, sudo, or platform account configuration.

Test a Caller Outside the Group

Switch from labex to testuser2, using DemoOther123!:

su - testuser2

From that shell, attempt the scoped target using its correct password DemoTarget123!:

su - su-lab-target

This must fail with an authentication error because testuser2 is not in sugroup. A failed su does not create a new shell. Exit once to return to labex:

exit
whoami

Confirm that whoami reports labex before continuing.

Test a Caller Inside the Group

Switch to testuser using its DemoUser123! password from step 1:

su - testuser
id
su - su-lab-target

Enter DemoTarget123! for the target. This switch should succeed. Confirm the target identity:

whoami

The output should be su-lab-target. Two shells were opened, so exit twice: first to testuser, then to labex:

exit
exit
whoami

Confirm that whoami reports labex. Never run the restoration command from a disposable user's shell.

Restore the Original Policy

From labex, restore the saved configuration and compare it with the original:

sudo cp -p /opt/labex/su-demo/pam-su.original /etc/pam.d/su
sudo cmp /opt/labex/su-demo/pam-su.original /etc/pam.d/su

A successful comparison prints nothing. The demonstration group and users remain available for diagnosis, while su uses its original policy again.

Troubleshooting and Resolving Su Authentication Failures

In this step, you will use a systematic process to troubleshoot and resolve su authentication failures.

Diagnosing Authentication Failures

When you encounter an su authentication failure, follow these systematic steps to diagnose the issue:

Step 1: Check the Error Message

The error message can provide valuable clues about the nature of the failure. Common error messages include:

• su: Authentication failure - Typically indicates an incorrect password.
• su: user username does not exist - The specified user account does not exist.
• su: permission denied - Access control restrictions are preventing the operation.

Step 2: Verify the User Account

Ensure that the target user account exists and is not locked:

grep testuser /etc/passwd

This should display the entry for testuser in the password file, confirming the account exists.

Check if the account is locked:

sudo getent shadow testuser | cut -d: -f2 | cut -c1

This shows only the first character of the disposable account password field, not the password hash. A leading ! means password authentication is locked.

Step 3: Check for Access Control Restrictions

As we learned in the previous step, PAM configuration can restrict su access. Check for such restrictions:

grep -v "^#" /etc/pam.d/su | grep pam_wheel

If this returns a line containing pam_wheel.so, access to su might be restricted to members of a specific group.

Step 4: Examine System Logs

The failed login records can provide useful information about authentication failures:

sudo lastb | head

Look for entries related to your failed su attempts, which can provide additional context.

Resolving Common Su Authentication Failures

Now, let us address common su authentication failures and how to resolve them:

1. Incorrect Password

If you are entering the correct password but still getting authentication failures, the password might need to be reset:

printf '%s\n' 'testuser:DemoUser123!' | sudo chpasswd

This resets only the disposable testuser password to the known practice value; it does not change labex or root.

2. Account Locked

If the account is locked, unlock it:

sudo usermod -U testuser

3. Access Control Restrictions

If access control restrictions are preventing su access, you can either:

a. Add the user to the required group:

sudo usermod -aG sugroup testuser2

This adds testuser2 to the sugroup.

b. For this lab, remove only the demonstration policy by restoring the original saved file:

sudo cp -p /opt/labex/su-demo/pam-su.original /etc/pam.d/su

This restores the exact original su policy instead of disabling arbitrary authentication rules.

4. File Permission Issues

Inspect the su binary permissions without changing the platform binary:

ls -l "$(command -v su)"

The expected setuid bit is shown as s in the owner execute position. If the platform binary is damaged, use a fresh VM rather than changing its permissions.

Testing the Fixes

After applying the fixes, test if su authentication works correctly:

su - testuser

Enter the password for testuser when prompted. If successful, you should now be logged in as testuser.

Run whoami to confirm testuser, then run exit once to return to labex. Do not use root password login as a success test: the disposable-account login is the positive case.

These troubleshooting steps and fixes address the most common su authentication failures. By systematically diagnosing and resolving these issues, you can ensure that the su command functions correctly on your system.

Best Practices for Secure Su Usage

In this step, you will review safe privilege use and confirm that the demonstration left platform access unchanged.

Prefer Sudo for Individual Administrative Commands

Sudo can grant and log individual administrative actions without sharing the root password. From your labex shell, list the root home directory without starting a root login shell:

sudo ls /root

Keep the platform's existing sudo policy. You can inspect your allowed commands without changing the policy:

sudo -l

Keep Authentication Changes Scoped

On production systems, administrators manage root login, password quality, and authentication policy through approved configuration workflows. This exercise does not change SSH settings, the labex password, or labex group membership. A strong password policy or multi-factor authentication requires its own implementation; neither is configured by this tutorial.

Confirm that the temporary su policy was removed:

sudo cmp /opt/labex/su-demo/pam-su.original /etc/pam.d/su

No output means the policy matches the saved original.

Audit Failed Authentication Attempts

Use the failed-login database to investigate unsuccessful attempts:

sudo lastb | head

This reads /var/log/btmp; it does not show every successful su session. Interpret only records actually written by the system, and investigate repeated failures in a production environment.

Use a Login Environment and Return Explicitly

The dash option starts the target user's login environment. Use the testuser password DemoUser123!:

su - testuser
whoami
exit
whoami

The two identity checks should show testuser and then labex. The exit closes only the shell created by su. The VM retains its original platform login, sudo access, and su policy.

Summary

In this lab, we explored the su command in Linux and learned how to troubleshoot common authentication failures. We covered:

1. Understanding the basic usage of the su command and how it works
2. Identifying common causes of su authentication failures, including incorrect passwords, account restrictions, and PAM configuration issues
3. Configuring access control for the su command to enhance security
4. Troubleshooting and resolving su authentication failures through systematic diagnosis
5. Implementing best practices for secure su usage, including using sudo when possible, configuring robust password policies, and regularly auditing su usage

By applying these techniques and best practices, you can ensure that the su command functions correctly while maintaining the security of your Linux system. Remember that proper authentication management is a crucial aspect of system administration and security.