RHEL Operations Audit Lab

Launch a RHEL 9 EC2 lab, patch it, inspect SSH sessions, and automate audits.

Introduction

30 Second Summary

A server can look healthy while important details stay hidden. When something changes, clear evidence shows what happened.

In this project, you will build a disposable Red Hat Enterprise Linux 9 operations lab on Amazon EC2. From your Mac, you will use SSH to administer the host while Bash gathers session, service, storage, and update evidence in one report.

What You'll Build

You will run your Bash script from an SSH session to print a timestamped operations report that shows the host's identity, service health, active sessions, storage, and available updates.

By the end of this project, you'll have:

A restricted RHEL 9 server that you can reach from your Mac over SSH.
Command-line administration evidence showing a local account, supplementary group membership, shared-directory permissions, concurrent sessions, and authentication activity.
A repeatable maintenance workflow that uses DNF for security updates before Bash saves the audit evidence to $HOME/rhel-audit.txt.
Secret Mission: Investigate a controlled failed SSH login through SSH service logs before documenting the event in a short incident note.

Are there any prerequisites?

You need an AWS account with billing enabled, a Mac with Terminal, and basic Linux command knowledge. The lab uses paid AWS resources for about one hour. The cleanup section shows you how to terminate the lab promptly after you review the displayed price.

Before We Start

A public cloud lab gives you a safe place to practise Red Hat Enterprise Linux administration. It cannot establish experience inside a classified environment.

Before anything is launched in AWS, this checkpoint confirms that your account and local tools are ready. It also frames the experience accurately before you create paid resources.

In this step, get ready to:

Confirm that your AWS account and Mac meet the lab prerequisites.
Describe the project as public-cloud lab practice with Bash automation.
Verify that your SSH client is ready for a remote connection.

Confirm the lab prerequisites

Amazon EC2 provides the remote server for this lab. Its compute capacity can incur charges.

Billing checks can feel risky. This step creates no AWS resources, so it incurs no lab charges.

Confirm that you can sign in to an AWS account with billing enabled.
Confirm that you have permission to incur temporary AWS charges.
Confirm that you are using a Mac.
Press Command-Space bar to open Spotlight.
Type VS Code into Spotlight.
Confirm that VS Code appears in the search results.
Press Esc to close Spotlight.
Confirm that you are comfortable entering basic Linux commands in a terminal.

Frame the lab accurately

This public-cloud exercise produces evidence of skills you can reproduce safely. Your project statement should describe that scope clearly.

Draft one sentence that describes the project as a disposable RHEL operations lab.
Name these practice areas: administration, session investigation, patching, Bash automation.
State that the work represents public-cloud lab practice without claiming classified-system experience.

Verify the local SSH client

OpenSSH provides the client you will use to connect to the remote RHEL server. Running it without a destination checks that the command is available.

Press Command-Space bar to open Spotlight.
Type Terminal into Spotlight.
Press Return to open macOS Terminal.

Before you run the check, what do you expect the client to print when no remote host is supplied?

Check whether OpenSSH is available by running this command:

ssh

What Does This Check Prove?

The ssh command starts the local SSH client.
Running it without a destination prompts the client to print usage guidance.
Usage output confirms that the client is installed and responding.

You should see SSH client usage information in Terminal. This confirms that your Mac is ready to start a remote connection.

Seeing Command Not Found?

If the output mentions command not found, confirm that you opened macOS Terminal through Spotlight.

Still stuck? Help me verify the SSH client on my Mac.

Good start. Your SSH client is ready for a real connection.

Next, you will launch the RHEL server. You will connect to it from this Terminal window.

Launch and Connect to RHEL

The rest of this lab needs a real enterprise Linux host. That host gives each administration task a credible source of evidence.

You will launch Red Hat Enterprise Linux 9 on Amazon EC2. You will restrict SSH access to your current public IP before connecting from your Mac.

In this step, get ready to:

Select the subscription-included RHEL 9 marketplace image.
Launch rhel-ops-lab with a restricted SSH rule.
Connect from macOS Terminal to verify the operating system.

Select the RHEL 9 image

An Amazon Machine Image (AMI) supplies the operating system used to create an EC2 instance. AWS Marketplace provides the subscription-included RHEL image for this lab.

Sign in to the AWS Management Console with your AWS account.
Use the console search bar to search for Amazon EC2.
Select Amazon EC2 from the search results.
Choose Launch instance.

The EC2 launch wizard now shows the settings that define your new server.

Choose Browse more AMIs under Application and OS Images (Amazon Machine Image).
Open AWS Marketplace AMIs.
Search for Red Hat Enterprise Linux 9.
Select the AWS Marketplace product Red Hat Enterprise Linux 9 (HVM).
Choose the current RHEL 9 version shown for the 64-bit x86 delivery.
Confirm the delivery option says 64-bit (x86) Amazon Machine Image (AMI).

The reference listing reports 9.6 v20250618. AWS may show a newer RHEL 9 build when the product is refreshed.

Good progress. The launch wizard now has the enterprise Linux image that powers your lab.

Why RHEL for this lab?

RHEL aligns directly with the Linux administration skills this lab practises. Native SSH access keeps your attention on the server workflows you need to demonstrate.

Configure and launch the instance

A security group controls inbound traffic to your instance. A /32 source limits the SSH rule to one public IPv4 address.

The default Amazon EBS root volume stores the RHEL operating system. It remains attached to the instance until you terminate the lab.

Enter rhel-ops-lab as the instance name.
Select t3.micro under Instance type.

The instance summary now identifies your lab by name. It also shows the selected instance size.

Start creating a new key pair under Key pair (login).
Enter rhel-ops-lab as the key pair name.

The key pair form now shows the name that links your private key to this EC2 instance.

Select pem as the private key file format.
Finish creating the key pair.

Your browser downloads rhel-ops-lab.pem as soon as the key pair is created.

Move rhel-ops-lab.pem into ~/Downloads if your browser saved it elsewhere.

The private key now has a predictable local path. You will use that path when connecting from Terminal.

Configure the inbound rule under Network settings for SSH over TCP port 22.
Set the rule source to your current public IPv4 address with a /32 suffix.

The inbound rule should display your public IPv4 address followed by /32. A source of 0.0.0.0/0 would expose port 22 to every IPv4 address.

Keep the EBS root volume attached under Configure storage.
Review the Marketplace pricing shown in the launch wizard.

This is the billing point in the lab. The RHEL software charge is included in the associated EC2 infrastructure costs.

You will terminate the instance during cleanup. Prompt termination keeps this paid lab temporary.

Create the instance by choosing Launch instance.

Provisioning can take a few minutes. That wait means AWS is creating the instance plus its attached resources.

Wait until rhel-ops-lab shows a running state in Amazon EC2.

Your RHEL server is now running. Its SSH rule accepts connection attempts only from the public IPv4 address you configured.

Instance did not launch?

Review the launch settings for any field that AWS has highlighted.
Confirm your AWS account has billing enabled.
Confirm the selected image is the RHEL 9 marketplace product.

Need help narrowing it down? Help me troubleshoot why my RHEL 9 EC2 instance did not launch.

Protect the key and connect

Your private key proves that your Mac is allowed to connect as ec2-user. Restrictive file permissions prevent other local accounts from reading that key.

Return to the macOS Terminal window you used earlier.
Protect the downloaded private key by running this command:

chmod 400 ~/Downloads/rhel-ops-lab.pem

What does this command do?

The 400 mode gives your account read access to the private key. This restriction allows OpenSSH on macOS to use the file.

Terminal should return control without reporting a permission problem.

Key permission command failed?

Confirm the downloaded file is named rhel-ops-lab.pem.
Confirm the file is stored in ~/Downloads.
Rerun the permission command after correcting the file name or location.

Still blocked? Help me fix the permissions or path for my EC2 private key.

Return to the rhel-ops-lab instance in the Amazon EC2 console.
Choose Connect.
Open the SSH client instructions.
Copy the generated SSH command.
Compare the generated command with this expected pattern:

ssh -i ~/Downloads/rhel-ops-lab.pem ec2-user@<public-dns>

How does the SSH command work?

The -i option points SSH to your private key.
The ec2-user value is the default username for this RHEL image.
The public DNS name sends the connection to your specific EC2 instance.

The first connection asks you to confirm the host key. Check the displayed host against the public DNS name in Amazon EC2 before accepting it.

Run the generated command you copied in macOS Terminal.
Compare the host shown in the prompt with your instance public DNS name.
Accept the host key after the host matches.

You are connected when Terminal shows a remote shell prompt for ec2-user. Your Mac can now administer the RHEL host through the restricted SSH rule.

SSH connection did not open?

Confirm rhel-ops-lab still shows a running state in Amazon EC2.
Confirm the security group source matches your current public IPv4 address with a /32 suffix.
Confirm the generated command points to ~/Downloads/rhel-ops-lab.pem.

Need help with the connection? Help me troubleshoot my SSH connection to the RHEL 9 EC2 instance.

Before you check the release file, what RHEL major version do you expect the server to report?

Verify the operating system identity by running this command in the SSH session:

cat /etc/os-release

What does this command check?

The /etc/os-release file contains the operating system metadata for the host. Reading it proves which Linux distribution your instance is running.

You should see output that identifies Red Hat Enterprise Linux 9. That result confirms the marketplace image launched correctly.

Release output looks different?

Compare the distribution name with the selected AMI in Amazon EC2.
Confirm you connected to the public DNS name for rhel-ops-lab.

Unsure what the output means? Help me interpret my RHEL operating system release output.

Your RHEL 9 server is live. Next, you will establish its account, service, storage, and permission baseline.

Build an Administration Baseline

Your Red Hat Enterprise Linux host is reachable from the last step. A reachable server still needs an administration baseline before it can support reliable operations.

A useful baseline starts with the host identity. This confirms which operating system you are administering.

The SSH service tells you whether remote administration is available. Root storage shows the capacity available for administrative work.

A local user attaches activity to a named account. A supplementary group controls access to a shared report directory.

In this step, get ready to:

Record the host baseline.
Create a local user with supplementary group membership.
Prepare a group-controlled report directory.

Record the host and service baseline

The baseline uses three read-only checks. Each check answers a different operational question.

Collect the host baseline by running these commands:

cat /etc/os-release
systemctl is-active sshd.service
df -P /

What do these checks prove?

The cat command reads operating system metadata from /etc/os-release.
The systemctl command asks systemd whether sshd.service is running.
The df command reports portable file system capacity information for /.

Confirm the release output identifies Red Hat Enterprise Linux 9.
Confirm the service status output is active.
Identify the root file system's total space.
Identify the root file system's used space.
Identify the root file system's available space.

Baseline output look different?

A different service result can mean the command ran on your Mac. Check that your terminal prompt is still inside the RHEL SSH session.

If the disk report does not include the root file system, check that the final command ends with /.

Need a hand? Help me troubleshoot my RHEL baseline checks.

Create and group a local account

A local user gives administrative activity a named account. A supplementary group grants shared access without changing the account's primary group.

Create the local account and supplementary group by running these commands:

sudo useradd example.user
sudo groupadd example.group
sudo usermod -a -G example.group example.user

What do these commands create?

The useradd command creates the local account named example.user.
The groupadd command creates the local group named example.group.
The usermod command appends example.group to the account's supplementary group membership.

Verify the account and its supplementary membership by running these commands:

id example.user
groups example.user

What do the identity checks show?

The id output identifies the account's user ID plus its group memberships.
The groups output provides a focused list of groups associated with the account.

You should see example.user in the identity output. You should also see example.group in the supplementary group list.

Account or group missing?

A missing account usually means the first command did not complete. Scroll up to find the command that reported a problem.

A missing group membership can come from a typo in either name. Compare both identifiers with example.user plus example.group.

Still stuck? Help me troubleshoot the RHEL user and group setup.

Create a group-controlled report location

The set-group-ID permission makes new content inherit the directory's group ownership. Group read, write, plus execute permissions let members use the directory as a shared location.

Create the directory and apply its group controls by running these commands:

sudo mkdir /srv/ops-reports
sudo chgrp example.group /srv/ops-reports
sudo chmod g+rwxs /srv/ops-reports

How do the directory controls work?

The mkdir command creates /srv/ops-reports.
The chgrp command assigns example.group as the directory's group owner.
The chmod command applies g+rwxs to the directory's group permissions.

Before you run the final check, consider whether the account will show its supplementary group. Also picture the permission marker you expect on the shared directory.

Verify the complete baseline by running these commands:

id example.user
groups example.user
ls -ld /srv/ops-reports

What does the final check prove?

The first command proves that example.user exists.
The second command proves that example.group is associated with the account.
The directory listing proves that the shared location has the expected group owner plus permission marker.

You should see example.user in the identity output. You should also see example.group as a supplementary group.

The directory listing should name example.group as the group owner. The group permission field should include the s marker.

Directory permissions look different?

If the group owner is different, check the group name used with chgrp.

If the s marker is missing, check that the permission value was entered as g+rwxs.

Need help reading the result? Help me diagnose the report directory permissions.

That is a solid baseline complete. Each administrative control now has visible command-line evidence.

Next, you will use two concurrent SSH connections to watch session evidence change in real time.

Locate User Session Evidence

Your RHEL host now has a verified account baseline. The shared report directory also has the group permissions an administrator expects.

Permissions do not show who is connected right now. A session investigation pairs the live view from who with current-boot SSH records in the systemd journal.

In this step, get ready to:

Demonstrate two concurrent SSH sessions in who.
Inspect current-boot records for sshd.service.
Confirm a closed session disappears from who.

Create concurrent SSH sessions

Each remote login gets its own terminal identifier. Two concurrent connections make that live evidence easy to compare.

Keep the first SSH session from earlier connected.
In macOS Terminal, press Command-N to create a second window.
In the second window, run the same SSH command from Step 1.

You should see a remote shell prompt for ec2-user in the second window. Both SSH sessions are now connected to the same host.

Before you check, how many current login rows do you expect to see?

List the current login sessions from the first SSH window by running:

who

How Does who Help?

The who utility reports each current login session as a separate row.
The terminal identifier distinguishes one connection from another.
The login time establishes when each session began.

You should see two rows for ec2-user with different terminal identifiers. That output is your live evidence that two connections are active.

Only Seeing One Session?

Check the second Terminal window for a remote shell prompt.
Reconnect from the second window before rerunning who if the SSH session ended.
Still stuck? Help me find why who only shows one SSH session..

Inspect SSH authentication activity

A live session list captures the present moment. Service records preserve evidence about how SSH handled connections during the current boot.

Inspect the current-boot SSH service records from the first session by running:

sudo journalctl -b _SYSTEMD_UNIT=sshd.service

What Does This Command Show?

The -b option limits the journal to the current boot.
The _SYSTEMD_UNIT=sshd.service filter selects records from the SSH service.
The resulting timeline connects service activity to the sessions you observed.

Locate the records associated with your successful SSH connections.
Compare their timestamps with the login times from who.
Press q to exit the journal pager.

You should find current-boot SSH service records that line up with your connections. The journal provides a historical trail beyond the live session rows.

Cannot Find the Connection Records?

Confirm you ran the command inside the valid RHEL SSH session.
Check that the filter exactly matches _SYSTEMD_UNIT=sshd.service.
Need another pair of eyes? Help me locate successful SSH connections in the systemd journal..

Observe the session state change

The live session list changes when a connection closes. The journal retains the service activity from that connection for the current boot.

Switch to the second SSH window.
Close its remote shell by running:

exit

What Does exit Change?

The exit command closes the remote shell in the second window. Your first SSH session stays connected.

The second window should return to your local Mac shell prompt. The host now has one current login session.

Before you rerun the live check, which terminal row do you expect to disappear?

Return to the first SSH session.
List the remaining current sessions by running:

who

Why Did the Live Row Disappear?

The who utility queries sessions that are active when you run it. Closing the second shell removes its row from that live view.

The journal keeps the earlier SSH service activity from the current boot. An administrator can still investigate the connection after it ends.

You should now see one ec2-user row. The terminal identifier from the closed session has disappeared.

Still Seeing Two Sessions?

Confirm that exit returned the second window to its local Mac prompt.
Rerun who from the first remote session after the second connection closes.
Need help comparing the rows? Help me identify which SSH session is still active..

You can now prove who is connected and trace how SSH handled those connections. Next, you will patch the host and repeat its operational checks.

Patch the Operating System and Bash

Your earlier SSH session investigation proved that the host records live connections. It also proved that the journal keeps service evidence.

A patched host still needs service health evidence before maintenance can be considered complete. It also needs current session data.

This step applies security updates to Red Hat Enterprise Linux. You will also verify the installed Bash package.

In this step, get ready to:

Assess packages with available updates.
Apply available operating system security updates.
Update Bash before repeating the post-update health checks.

Assess pending updates

DNF compares installed packages with the versions available from enabled repositories. Assessing the host first gives you a clear before-state.

Switch back to the valid SSH session from earlier.
Assess the available package updates by running this command:

sudo dnf check-update

What does this check show?

The command lists installed packages with available updates.
The output also identifies dependencies that have newer versions available.
A recently published image can have no pending updates.

You will either see a list of packages that can be updated or no pending package entries. Both results give you a valid maintenance baseline.

Unable to retrieve update information?

Confirm that the existing SSH session still accepts input.
Retry the command once if repository access was interrupted.

Still blocked? Help me diagnose the DNF update check.

Apply security updates

A security-only upgrade limits the package transaction to updates associated with security errata. DNF displays a transaction summary before changing installed packages.

This transaction can take several minutes while packages download. A quiet terminal during that time does not mean the session has stopped.

Start the security update transaction by running this command:

sudo dnf upgrade --security

What does this command do?

The security filter selects available packages that have security errata.
The transaction summary shows the affected packages before installation starts.

Review the package list when DNF displays the transaction summary.
Confirm the transaction after checking that the package list matches the security update scope.
Use the checkpoint below to record whether a kernel package changed.
Keep the disposable lab running so you can save its evidence in later steps.

DNF installs every available security update that you approved. A host with no applicable security updates remains current without changing packages.

Security transaction unable to continue?

Wait for any other active package transaction to finish before retrying the command.
Check that your SSH session remains connected before restarting the transaction.

Need another pair of eyes? Help me troubleshoot the security update transaction.

Update Bash and repeat the checks

Bash is an application package on the host. Updating it separately demonstrates how to target one named package after the broader security transaction.

Start the Bash package update by running this command:

sudo dnf upgrade bash

What does this package update do?

DNF checks enabled repositories for a newer Bash package.
The transaction targets Bash plus any required dependencies.

Review the transaction summary if DNF offers a Bash update.
Confirm the transaction after checking the listed package.

DNF installs the available Bash update or reports Nothing to do when the package is already current.

Bash update unable to finish?

Check that the security update transaction has fully completed.
Retry the Bash update after any active package process finishes.

Still seeing a package problem? Help me troubleshoot the Bash update.

Before you inspect the package, predict whether Bash is already current or has a newer repository version available.

Verify the installed Bash package details by running this command:

dnf info bash

What should the package details prove?

The installed package section identifies the Bash version currently present on the host.
The repository information shows whether a newer package version remains available.

You should see the installed Bash package details. You may also see a newer repository version if another update remains available.

Bash package details missing?

Check the command spelling if no Bash package information appears.
Confirm that DNF can still reach the enabled repositories.

Need help reading the result? Help me interpret the Bash package information.

Maintenance ends with a health check. The familiar commands test the host after its package changes.

Before you run this checklist, predict whether all three health signals stayed stable after patching.

Repeat the post-update health checklist by running these commands:

systemctl is-active sshd.service
who
df -P /

What does this checklist verify?

The service check confirms whether the SSH server remains active.
The session check lists the users currently connected to the host.
The disk check reports total space for the root file system.
The disk check also reports used space and available space.

You should see active for sshd.service. The who output should show your current ec2-user session.

The final table should show the root file system's total space. It should also show used space plus available space.

Post-update health check looks wrong?

Inspect the SSH service status if the first command does not report an active service.
Confirm that you are reading the row for the root file system in the disk output.
Check the current terminal row if the session output differs from the earlier two-session result.

Need help interpreting a result? Help me diagnose the post-update health checks.

The host is healthy. The workflow still required three separate checks after one package task.

That repetition is easy to omit during routine maintenance. This is the manual gap you were meant to uncover.

You have patched the host while preserving its service health. Next, you will replace the repeated checks with one Bash-generated audit report.

Automate the Audit with Bash

Your post-update checks proved that the host remains observable after patching.

Repeating that checklist by hand is slow. A Bash script collects the same evidence consistently in one run.

In this step, get ready to:

Create ~/rhel-audit.sh with the audit commands.
Generate the ~/rhel-audit.txt report.
Validate the evidence in every report section.

Create the audit script

An audit script should be reusable across hosts. This script contains no credentials, private keys, or public DNS names.

The vi editor opens inside your SSH terminal. You return to the shell after saving and closing it.

In the connected SSH session from earlier, open ~/rhel-audit.sh by running this command:

vi ~/rhel-audit.sh

What does this command do?

This command loads ~/rhel-audit.sh in the terminal editor. Saving the buffer creates the script in the ec2-user home directory.

Press i to enter insert mode.
Paste the complete script below into ~/rhel-audit.sh:

report_file="$HOME/rhel-audit.txt"

echo "RHEL OPERATIONS AUDIT" > "$report_file"
echo "Generated: $(date)" >> "$report_file"
echo >> "$report_file"
echo "OS RELEASE" >> "$report_file"
cat /etc/os-release >> "$report_file"
echo >> "$report_file"
echo "SSHD STATUS" >> "$report_file"
systemctl is-active sshd.service >> "$report_file"
echo >> "$report_file"
echo "ACTIVE LOGIN SESSIONS" >> "$report_file"
who >> "$report_file"
echo >> "$report_file"
echo "ROOT FILESYSTEM" >> "$report_file"
df -P / >> "$report_file"
echo >> "$report_file"
echo "AVAILABLE PACKAGE UPDATES" >> "$report_file"
dnf check-update >> "$report_file" 2>&1

cat "$report_file"

What does this script collect?

The report_file variable keeps the report destination in one place.
The initial > starts a fresh report. Each >> adds evidence below it.
The date command records when the audit ran.
The cat /etc/os-release command records the operating system identity.
The SSH service command records whether sshd.service is active.
The who command records current login sessions.
The df -P / command records root file-system capacity.
The DNF check records the available-update results. The 2>&1 redirection keeps its diagnostic output in the report.
The final cat command prints the completed report to the terminal.

Press Esc to return to command mode.
Type :wq to write the file.
Press Enter to close the editor.

You'll return to the shell prompt. The next run proves that the saved script works.

Still inside the editor?

Press Esc before entering :wq.
Compare your script with the full-code tab if the pasted lines look incomplete.

Still stuck? Help me save and close this Bash script in vi.

✔️ Awesome, I've got everything!

Your saved rhel-audit.sh now contains the full audit collector.

ⓧ I'd like to double check the full code

report_file="$HOME/rhel-audit.txt"

echo "RHEL OPERATIONS AUDIT" > "$report_file"
echo "Generated: $(date)" >> "$report_file"
echo >> "$report_file"
echo "OS RELEASE" >> "$report_file"
cat /etc/os-release >> "$report_file"
echo >> "$report_file"
echo "SSHD STATUS" >> "$report_file"
systemctl is-active sshd.service >> "$report_file"
echo >> "$report_file"
echo "ACTIVE LOGIN SESSIONS" >> "$report_file"
who >> "$report_file"
echo >> "$report_file"
echo "ROOT FILESYSTEM" >> "$report_file"
df -P / >> "$report_file"
echo >> "$report_file"
echo "AVAILABLE PACKAGE UPDATES" >> "$report_file"
dnf check-update >> "$report_file" 2>&1

cat "$report_file"

Generate the report

Each run replaces the previous report with a fresh snapshot. This gives every audit a new timestamp and current command output.

Before you run the script, which service and session details do you expect it to capture?

Generate ~/rhel-audit.txt by running this command:

bash ~/rhel-audit.sh

What happens when the script runs?

Bash executes each collector in order. The script saves the results in ~/rhel-audit.txt before printing the same report.

You'll see the RHEL OPERATIONS AUDIT title with a generated date.
You'll see RHEL release data under OS RELEASE.
You'll see active under SSHD STATUS.
You'll see login data under ACTIVE LOGIN SESSIONS.
You'll see root file-system usage under ROOT FILESYSTEM.
You'll see the repository check results under AVAILABLE PACKAGE UPDATES.

You have turned the repeated post-update checklist into one command.

Report did not print?

Check that the script path is ~/rhel-audit.sh.
Compare every quote and redirection symbol with the full-code tab if Bash reports a syntax problem.
Confirm that cat "$report_file" remains the final line.

Need another pair of eyes? Help me troubleshoot why my RHEL audit report is not printing.

Validate the evidence

Reliable audit evidence needs complete sections and usable output. An unusual result tells an administrator where to investigate next.

Before you print the saved file, which headings should remain available after the script has finished?

Print the saved report by running this command:

cat ~/rhel-audit.txt

What does this check prove?

Reading ~/rhel-audit.txt separately proves that the evidence persists after the script finishes. Another administrator can review the saved snapshot without rerunning every check.

Confirm that OS RELEASE contains RHEL release data.
Confirm that SSHD STATUS contains active.
Confirm that ACTIVE LOGIN SESSIONS contains the current session row.
Confirm that ROOT FILESYSTEM contains the root file-system usage row.
Confirm that AVAILABLE PACKAGE UPDATES reflects the current repository check.

What should unusual results trigger?

An SSH status other than active points to a service health investigation.
A nearly full root file system points to storage usage and capacity investigation.
Pending package updates call for review before the next approved maintenance action.

Before the final run, do you expect the same report sections to appear with a newly generated time?

Prove that the audit is repeatable by running the script again:

bash ~/rhel-audit.sh

What should this rerun prove?

The rerun refreshes ~/rhel-audit.txt with current evidence. It prints the refreshed report in the same command.

You'll see RHEL OPERATIONS AUDIT followed by a generated date.
You'll see the RHEL release information.
You'll see active SSH service status.
You'll see the current login session rows.
You'll see root file-system usage.
You'll see the available-update results.

Your RHEL host now produces a timestamped operations audit whenever you run the script.

Is a report section missing?

Compare the missing heading with the matching command in the full-code tab.
Check that each evidence command uses >> "$report_file" so its output reaches the report.
Check that dnf check-update includes 2>&1 so diagnostic output is captured.

Still missing evidence? Help me find why a section is absent from my RHEL audit report.

Secret mission

Investigate a Failed SSH Login

Create one controlled failed SSH login from your Mac. Trace the attempt in the server journal and turn the evidence into an incident note that another administrator can follow.

Clean Up Your Resources

This lab can incur charges while its Amazon EC2 instance uses Red Hat Enterprise Linux software and attached EBS storage. Decide whether to keep the lab running, pause it for later, or delete it entirely.

Cost warning

The running t3.micro instance can incur compute charges. RHEL software charges, attached storage, and some network usage can add to the cost.

Terminate the lab promptly if you have finished using it.

Resources you used:

Running Amazon EC2 instance named rhel-ops-lab using a subscription-included RHEL 9 image.
Attached EBS root volume containing the remote server state.
EC2 key pair named rhel-ops-lab.
Security group containing the restricted SSH access rule.
Local private key file at ~/Downloads/rhel-ops-lab.pem.
Remote RHEL state containing example.user, example.group, /srv/ops-reports, ~/rhel-audit.sh, ~/rhel-audit.txt, and ~/ssh-investigation.txt.

Keep everything running

No action needed. Choose this if you want to continue practising RHEL administration on the live server.

The rhel-ops-lab instance stays available for SSH connections.
Applicable instance, RHEL software, storage, and network charges continue.
The security group continues to restrict SSH access to your current public IPv4 /32 source.
The remote accounts, directory, script, and evidence files remain on the server.

Pause - I'll come back to this later

Stop the EC2 instance to pause compute use while preserving the lab. Compute charges stop while the instance is stopped, but attached EBS storage can continue to incur charges.

Return to the valid macOS Terminal SSH session from earlier.
Run exit to close the SSH connection.
In the Amazon EC2 instance list from earlier, select rhel-ops-lab.
Use the instance-state control to stop the selected instance.
Confirm that the instance reaches the stopped state.

Delete - I don't want to use this again

Termination is permanent, so take a moment to save any evidence you want before continuing. Remove every project resource to stop applicable charges and close the lab.

Copy ~/rhel-audit.txt from the instance to your Mac if you want to keep the operations report.
Copy ~/ssh-investigation.txt from the instance to your Mac if you want to keep the incident note.
Return to the valid macOS Terminal SSH session from earlier.
Run exit to close the SSH connection.
In the Amazon EC2 instance list from earlier, select rhel-ops-lab.
Choose Instance state.
Choose Terminate (delete) instance.
Confirm with Terminate (delete).
Wait until the instance reaches the terminated state.
In the EC2 volume list, confirm that the former root volume is no longer present.
Delete the former root volume if it remains after instance termination.
In the EC2 key pairs list, select rhel-ops-lab if no other instance uses it.
Delete the selected EC2 key pair.
In the EC2 security groups list, select the group that was attached to rhel-ops-lab if no other resource uses it.
Delete the selected security group.

Deleting the instance plus any surviving root volume removes all remote host state.

In Finder, open the Downloads folder in your home directory.
Select rhel-ops-lab.pem.
Move the selected private key file to Trash.
Confirm that rhel-ops-lab.pem no longer appears in the Downloads folder.

Nice Work!

Your disposable Red Hat Enterprise Linux 9 operations lab on Amazon EC2 is complete. It now holds practical evidence of administration, patching, session investigation, and Bash automation.

You've learned how to:

Build a secure RHEL server on Amazon EC2 with SSH restricted to your current public IP address. Administer a local user, a supplementary group, and a group-controlled report directory.
Trace concurrent user sessions from the command line. Correlate those sessions with current-boot SSH service evidence in the systemd journal.
Apply security updates with DNF. Check the Bash package for an available application update. Replace repeated checks with a timestamped audit report.
Secret Mission: Investigate a controlled failed SSH login in the current-boot journal. Record the timestamp, attempted account, source address, rejected result, and evidence command in an incident note.

Ready to quiz yourself?