Red Hat Enterprise Linux Diagnostics and Troubleshooting

Instructions

Over the weekend, colleagues ran user account maintenance. This morning, the student user reported that their student login no longer works on servera. The user states that their password is student, and that passwordless ssh normally works from the student account on workstation.

You verify that the user's expected settings are a home directory at /home/student, the UID and GID should both be 1000, and that this user's preferred shell is bash.

This exercise is intentionally simple, and is designed for you to practice including the scientific method in your troubleshooting work flow.

1. Begin by reproducing the problem, to collect relevant information. Record as much detail and information as possible about the issue.

   1. From a command prompt on workstation, attempt to use the ssh command to log in to the student account on servera.

      What do you notice, and what can be hypothesized from this information?

      [student@workstation ~]$ ssh student@servera
      Activate the web console with: systemctl enable --now cockpit.socket
      
      This system is not registered to Red Hat Insights. See https://cloud.redhat.com/
      To register this system, run: insights-client --register
      
      Connection to server closed.
      [student@workstation ~]$

      "The messages indicate that authentication succeeded, but the connection was closed immediately after."

   2. Open a console window to servera and attempt to log in as student with the password student. What happens?

      "The login proceeds without authentication error messages, but the session is closed immediately."

2. Gather more information about the target servera system.

   1. Attempt to use the ssh command to log in to the root account on the servera system.

      If required and unmodified, the password is redhat.

      [student@workstation ~]$ ssh root@servera
      ...output omitted...
      Last login: Wed Sep  1 17:06:02 2021 from 172.25.250.9
      [root@servera ~]# whoami
      root

      "Logging in to the root account succeeds."

   2. As the root user on servera, attempt to use the su - command to switch to the student account.

      [root@servera ~]# su - student
      Last login: Wed Sep  1 17:07:27 EDT 2021 from 172.25.250.9 on pts/0
      [root@servera ~]# whoami
      root

      "Switching to the student account did not succeed."

   3. Because the root account works, use it to gather information about the student account. Verify when student last successfully logged in.

      [root@servera ~]# lastlog -u student
      Username    Port    From                Latest
      student     pts/0                       Wed Sep  1 17:07:27 -0400 2021

      "This output verifies that the student user successfully logged in during previous tests, suggesting that something is causing the session to end prematurely."

   4. As root on servera, use the getent command to view the student user's settings.

      [root@servera ~]# getent passwd student
      student:x:1000:1000:Student User:/home/student:/bin/false

      "The student account is configured with the /bin/false shell, which restricts an account to non-interactive use only."

   5. Create a problem statement. Although the solution appears obvious, creating a problem statement is a proven technique to verify that you can accurately define the problem. If you researched that other users do not have the same problem, and that the problem does not occur for student to other servers, then here is an example of an accurate problem statement:

      "Since the previous weekend, the student user can access servera but is unable to create a working shell session. Because other users can start sessions on servera, and the student user can start sessions on other servers, the problem appears only with the student use of servera."

3. With the information that you gathered, form one or more hypotheses of what might be wrong with the student account.

   1. Looking at the getent output, note that the user's shell is set to /bin/false.

      "This shell is not a valid for interactive access, and is not the user's preferred shell."

   2. Formulate a test for your hypothesis.

      "If the shell is the problem, then test by changing the user configuration to the user's preferred shell and attempting the login again."

4. Reset the shell for student to /bin/bash, and then verify whether the problem is solved.

   1. Reset the shell for student on servera to /bin/bash.

      [root@servera ~]# chsh -s /bin/bash student
      Changing shell for student.
      Shell changed.

   2. Attempt to use the ssh command from workstation to log in to the student account on servera.

      [student@workstation ~]$ ssh student@servera
      ...output omitted...
      [student@servera ~]$

      "Login to a working shell is successful."

5. In this example, the only hypothesis proved to be the correct cause of the problem. In scenarios where there are more hypotheses, test each one and record the results.

   "Test: Modified the user account to use /bin/bash in the servera local user configuration and logged in again. Result: success."

6. After recording all test results, the final step is to choose and implement the best solution. During your testing, you verified on one test that the student user can access and create a shell on servera.

   The problem is resolved when the inverse of the original problem statement is true. For this scenario, this is an example of the inverse problem statement as the solution.

   "Currently, the student user can successfully access servera and create a working shell session."

7. Return to workstation as the student user.

   [student@servera ~]$ exit
   [student@workstation ~]$