RHCSA (035): Season 2 - Scenario 10: SSH Permission Matrix
RHCSA (035): Season 2 - Scenario 10: SSH Permission Matrix
Episode 035 Executive Summary
In this SSH Permission Matrix RHCSA lab scenario, I start performing the lab after a 6 minute introduction by the podcast hosts. You will get the most out of this lab if you listen to the entire show and then try to practice the lab several times, either along with me or by yourself. We are focusing on the critical intersection of user access and secure remote administration in a Red Hat Enterprise Linux 10 environment.
Many certification candidates understand basic file permissions and SSH access in isolation, but they often struggle when combining the two under strict security constraints. The deception in this scenario lies in the operational reality that SSH key authentication will completely fail if the underlying directory permissions are too permissive or incorrectly assigned. The goal here is to establish a secure, key-based access channel for an external auditing account while locking down the local filesystem to prevent unauthorized privilege escalation.
The core challenge involves creating a dedicated user, generating SSH keys, and enforcing exact permission octals on the required security directories. We will use standard user management tools alongside precision chmod and chown commands. Verification will consist of testing the local authentication mechanism directly and inspecting the permission tree to ensure full compliance with OpenSSH daemon security standards.
Keywords: Permissions, SSH, User Management, Key Authentication
EPISODE 035: SSH Permission Matrix
- Season: 2 | Difficulty: High
- Objectives: Primary 1.10 (Permissions), 1.4 (SSH); Secondary 9.1 (Create/Delete/Modify), 10.3 (SSH Keys)
- Lab Focus: User Access and Secure Authentication
- URL: https://djere.com/rhcsa-035-season-2-scenario-10-ssh-permission-matrix.html
1. SCENARIO BRIEF (THE PROBLEM)
A new security directive requires the creation of a local account named audit-user on your RHEL 10 server. This user must only be accessible via SSH key authentication. Furthermore, the SSH directory and authorized keys file must have the exact minimum permissions required by the sshd service, or the connection will be rejected. You must set up the user, configure the SSH key pair, position the public key correctly, and assign the proper filesystem permissions to guarantee secure remote access.
2. TASK ANALYSIS (THE "WHY")
- 1.10 (Permissions): OpenSSH enforces strict permission checks on the user home directory, the .ssh directory, and the authorized_keys file. If these are open to group or world writes, authentication fails.
- 1.4 (SSH): Securing remote access is a fundamental operational requirement.
- 9.1 (Create/Delete/Modify): Proper user creation ensures the account has the correct home directory skeleton and shell environment.
- 10.3 (SSH Keys): Transitioning away from password-based authentication mitigates brute-force attacks and represents modern infrastructure standards.
3. SOLUTION STEPS
Step 1: Environment Setup (Root Only)
# We must ensure the tar package is available for general system operations, though we rely primarily on base tools here.
if ! rpm -q tar; then dnf install -y tar; fi
# Create the dedicated user for auditing purposes. The -m flag ensures the home directory is generated.
useradd -m audit-user
# Lock the password for audit-user to prevent password-based logins, forcing key-based authentication.
passwd -l audit-user
Step 2: Core Implementation (Execute as Root)
# Switch to the audit-user to generate the SSH keys in their context, preventing ownership issues from the start.
su - audit-user -c "ssh-keygen -t ed25519 -N '' -f /home/audit-user/.ssh/id_ed25519"
# The public key must be added to the authorized_keys file to allow the local system to accept the incoming connection.
su - audit-user -c "cp /home/audit-user/.ssh/id_ed25519.pub /home/audit-user/.ssh/authorized_keys"
# We must explicitly set the permissions on the .ssh directory to 700 (read, write, execute for owner only) to satisfy SSH daemon security checks.
chmod 700 /home/audit-user/.ssh
# The authorized_keys file must be restricted to 600 (read and write for owner only) to prevent malicious modifications.
chmod 600 /home/audit-user/.ssh/authorized_keys
Technical Breakdown: The ssh-keygen command generates an ED25519 key pair with no passphrase for automation purposes. The chmod commands are strictly required by the OpenSSH daemon, which will silently ignore the authorized_keys file if the permissions allow group or other write access.
Pro-Tip: Exam environments frequently feature misconfigured permissions. If SSH key login fails, always check /var/log/secure and verify that the .ssh directory is exactly 700 and the authorized_keys file is exactly 600.
Step 3: Verification (The "Proof of Work")
# Test the SSH connection locally using the private key we just generated. The StrictHostKeyChecking=no flag bypasses the initial prompt for the lab environment.
ssh -i /home/audit-user/.ssh/id_ed25519 -o StrictHostKeyChecking=no audit-user@localhost "whoami"
EXPECTED: audit-user
# Verify the permission octals directly using the stat command to ensure they are perfectly aligned.
stat -c "%a %n" /home/audit-user/.ssh /home/audit-user/.ssh/authorized_keys
EXPECTED:700 /home/audit-user/.ssh
600 /home/audit-user/.ssh/authorized_keys
4. COMPREHENSIVE CLEANUP (ZERO-TRACE)
# Remove the audit-user and forcefully delete their home directory and mail spool to return the system to its initial state.
userdel -r audit-user