RHCSA (040): Season 2 - Scenario 15: Centralized SSH Key Linkage

Podcast: The RHCSA Series Podcast

  • Season: 2 (Episodes 26A - 50)
  • Episode: 40
  • Title: RHCSA (040): Season 2 - Scenario 15: Centralized SSH Key Linkage
  • Release date: August 25, 2026
  • Produced by: Djere Services Group
  • Associated article: https://djere.com/rhcsa-040-season-2-scenario-15-centralized-ssh-key-linkage.html

Episode 040 Executive Summary

In this Centralized SSH Key Linkage 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. Managing secure access across enterprise RHEL 10 environments often requires non-standard directory structures to support automated deployment pipelines and centralized configuration management systems.

This scenario presents a common real-world administrative challenge where a service user requires SSH key authentication, but system architecture dictates that the authentication keys must reside in a customized shared directory rather than the standard user home directory. Candidates frequently stumble here because creating a symbolic link to an external key file introduces strict security hurdles. The OpenSSH daemon enforceably checks ownership and permissions along the entire path, while the SELinux kernel subsystem actively blocks access if the target file lacks the appropriate context labels.

To resolve this challenge, you will generate an SSH keypair, implement a hard or symbolic link bridging the default SSH directory to the custom storage location, and configure the OpenSSH server to honor this setup. You will then utilize SELinux management utilities to permanently map and restore the security context on the custom directory path, ensuring the SSH daemon can read the linked key file without triggering access denials.

Keywords: RHEL 10, RHCSA, SSH, Symbolic Links, SELinux Contexts, SSH Keys, OpenSSH, semanage, restorecon, Linux Architecture

EPISODE 040: Centralized SSH Key Linkage

  • Season: 2 | Difficulty: High
  • Objectives: Primary 1.4 (SSH), 1.9 (Links); Secondary 10.3 (SSH Keys), 10.5 (SELinux Contexts)
  • Lab Focus: SSH Key Authentication, Symbolic Linking, SELinux File Contexts
  • URL: https://djere.com/rhcsa-040-season-2-scenario-15-centralized-ssh-key-linkage.html

1. SCENARIO BRIEF (THE PROBLEM)

An automated deployment application running on your RHEL 10 server must authenticate as the local user "deploy-manager" via SSH keys. Due to a system migration, all public keys for deployment services are now consolidated under the "/var/deployment/keys" directory. You must configure the user account so that its standard SSH authorized keys structure links directly to "/var/deployment/keys/authorized_keys". Furthermore, you must generate a new SSH keypair for testing, configure the OpenSSH daemon if required, and adjust the SELinux policy so that the SSH server can read key files from this non-standard file system location.

2. TASK ANALYSIS (THE "WHY")

  • 1.4 (SSH): The OpenSSH server enforces strict configuration and permission models; understanding how to manage access and verify remote execution is critical for remote system administration.
  • 1.9 (Links): Symbolic links provide a transparent mechanism to redirect file system read and write operations without duplicating data across disk partitions.
  • 10.3 (SSH Keys): Cryptographic keypair authentication eliminates password transmission over the network and is the required standard for automated service accounts.
  • 10.5 (SELinux Contexts): The Linux kernel enforces Mandatory Access Control policy rules; custom directory structures require explicit context mappings to permit daemon access.

3. SOLUTION STEPS

Step 1: Environment Setup (Root Only)

# Verify policycoreutils-python-utils is installed to provide the semanage command for SELinux policy management
if ! rpm -q policycoreutils-python-utils; then dnf install -y policycoreutils-python-utils; fi

# Create the dedicated deployment user account with a standard home directory and bash login shell
useradd -m -s /bin/bash deploy-manager

# Create the customized external directory structure to hold the centralized SSH keys
mkdir -p /var/deployment/keys

# Set exact directory ownership to the deployment user and group to satisfy SSH security requirements
chown -R deploy-manager:deploy-manager /var/deployment

# Apply restrictive directory permissions allowing read, write, and execute access exclusively to the owner
chmod 700 /var/deployment /var/deployment/keys

Step 2: Core Implementation (Execute as root)

# Generate a new 4096-bit RSA SSH keypair for the root user without a passphrase for automated login verification
ssh-keygen -t rsa -b 4096 -f /root/.ssh/deploy_test_key -N ""

# Copy the newly generated public key directly into the centralized target file
cat /root/.ssh/deploy_test_key.pub > /var/deployment/keys/authorized_keys

# Set ownership of the authorized keys file to the deployment user account
chown deploy-manager:deploy-manager /var/deployment/keys/authorized_keys

# Set strict permissions on the key file allowing read and write access only by the owner
chmod 600 /var/deployment/keys/authorized_keys

# Create the standard SSH configuration directory within the user home directory
mkdir -p /home/deploy-manager/.ssh

# Apply ownership and strict permissions to the standard user SSH directory
chown deploy-manager:deploy-manager /home/deploy-manager/.ssh
chmod 700 /home/deploy-manager/.ssh

# Create a symbolic link pointing from the standard SSH authorized keys location to the centralized target file
ln -s /var/deployment/keys/authorized_keys /home/deploy-manager/.ssh/authorized_keys

# Ensure the symbolic link itself is owned by the deployment user account
chown -h deploy-manager:deploy-manager /home/deploy-manager/.ssh/authorized_keys

# Add a permanent SELinux file context rule mapping the custom directory and its contents to the ssh_home_t domain
semanage fcontext -a -t ssh_home_t "/var/deployment(/.*)?"

# Apply the updated SELinux file context rules recursively across the custom directory structure
restorecon -Rv /var/deployment

# Technical Breakdown: When the SSH daemon processes a user login, it accesses the path "/home/deploy-manager/.ssh/authorized_keys". The file system redirects this read operation via the symbolic link to "/var/deployment/keys/authorized_keys". By default, files created in "/var" receive the "var_t" SELinux type, which the SSH daemon ("sshd_t") is explicitly blocked from reading. Mapping the "ssh_home_t" context to the external path satisfies the SELinux policy, allowing the daemon to read the public key and authenticate the user.

# Pro-Tip: OpenSSH will silently reject authentication if any directory in the entire path to the authorized keys file is writable by group or others (permissions 777, 775, or 755 with incorrect ownership). Always verify ownership and permissions from the root slash down to the target file when debugging SSH login failures.

Step 3: Verification (The "Proof of Work")

# Execute a remote command via SSH using the private test key, bypassing host key confirmation to verify successful authentication
ssh -i /root/.ssh/deploy_test_key -o StrictHostKeyChecking=no deploy-manager@localhost "whoami; ls -l /home/deploy-manager/.ssh/authorized_keys"
* EXPECTED:
deploy-manager
lrwxrwxrwx. 1 deploy-manager deploy-manager 36 Jul 25 15:24 /home/deploy-manager/.ssh/authorized_keys > /var/deployment/keys/authorized_keys

# Verify the SELinux security context on the external target directory explicitly shows the ssh_home_t type
ls -Zd /var/deployment/keys
* EXPECTED: unconfined_u:object_r:ssh_home_t:s0 /var/deployment/keys

4. COMPREHENSIVE CLEANUP (ZERO-TRACE)

# Terminate any active processes owned by the deployment user account before removal
pkill -u deploy-manager || true

# Remove the deployment user account and delete its home directory structure completely
userdel -r deploy-manager

# Remove the customized external deployment directory and all contained key files
rm -rf /var/deployment

# Remove the test SSH keypair generated in the root user home directory
rm -f /root/.ssh/deploy_test_key /root/.ssh/deploy_test_key.pub

# Remove the custom SELinux file context rule from the policy database
semanage fcontext -d -t ssh_home_t "/var/deployment(/.*)?"

You should also read:

RHCSA Series (005): Providing User Interfaces

Mind Map RHCSA_Series_5_Providing_User_Interfaces_Mind_Map │ ├── Alphabetical_List_of_Abbreviations │ ├── CLI = Command-Line Interface │ ├── CSCI = Computer Science │ ├── CSH = C…