Introduction
Managed node access is a foundation for Ansible automation. In real environments, Ansible usually connects over SSH and uses privilege escalation for administrative tasks.
In this lab, setup creates a disposable managed user named rhce_node. You will generate an SSH key, authorize it for that user, configure inventory access, and verify both normal SSH execution and become access.
Create the SSH Practice Project
In this step, you will create the project directories and Ansible defaults for SSH-based access. The managed account already exists, but it does not yet trust your key.
Create and enter the project.
cd /home/labex/project
mkdir -p rhce-ansible/{inventory,keys,playbooks}
cd rhce-ansible
Create ansible.cfg.
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
host_key_checking = False
retry_files_enabled = False
interpreter_python = auto_silent
EOF
This project uses a real SSH connection to 127.0.0.1 later in the lab. The keys directory keeps the lab key pair separate from your normal ~/.ssh files, and host_key_checking = False avoids an interactive prompt during this controlled local exercise.
Generate an SSH Key Pair
In this step, you will create an Ed25519 SSH key pair. The private key stays in keys/rhce_ed25519; the public key is safe to install on a managed account. The option -N '' creates a key without a passphrase for lab automation.
Before running commands in this step, return to the Ansible project directory. This keeps the commands stable even when LabEx runs each step separately.
cd /home/labex/project/rhce-ansible
Generate the key pair.
ssh-keygen -t ed25519 -f keys/rhce_ed25519 -N '' -C rhce-ansible-lab
This creates two files. keys/rhce_ed25519 is the private key and must stay private; keys/rhce_ed25519.pub is the public key that can be installed into the managed user's account.
Inspect the public key.
cat keys/rhce_ed25519.pub
The public key line should start with ssh-ed25519 and end with the comment rhce-ansible-lab. You will copy this public key, not the private key, into authorized_keys.
Authorize the Key for the Managed User
In this step, you will install the public key for the disposable managed user. You are not changing LabEx SSH access for the labex user; you are only preparing rhce_node for this lab.
Before running commands in this step, return to the Ansible project directory. This keeps the commands stable even when LabEx runs each step separately.
cd /home/labex/project/rhce-ansible
Create the managed user's .ssh directory.
sudo mkdir -p /home/rhce_node/.ssh
SSH looks for trusted public keys in the user's .ssh directory. You need sudo here because the directory belongs under another user's home directory.
Install your public key as authorized_keys.
sudo cp keys/rhce_ed25519.pub /home/rhce_node/.ssh/authorized_keys
Fix ownership and permissions. SSH refuses keys when directories or files are too open.
sudo chown -R rhce_node:rhce_node /home/rhce_node/.ssh
sudo chmod 700 /home/rhce_node/.ssh
sudo chmod 600 /home/rhce_node/.ssh/authorized_keys
The permission values are deliberate: 700 lets only rhce_node access the .ssh directory, and 600 lets only that user read or write authorized_keys. These checks prevent accidental exposure of login material.
Configure Inventory for SSH Access
In this step, you will create an inventory entry that tells Ansible how to connect to the managed user over SSH on localhost.
Before running commands in this step, return to the Ansible project directory. This keeps the commands stable even when LabEx runs each step separately.
cd /home/labex/project/rhce-ansible
Write the inventory.
cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_host=127.0.0.1 ansible_user=rhce_node ansible_ssh_private_key_file=/home/labex/project/rhce-ansible/keys/rhce_ed25519
EOF
This inventory line separates the Ansible name from the connection details. node1 is the inventory alias, ansible_host is the address to connect to, ansible_user is the remote account, and ansible_ssh_private_key_file points at the private key.
Test SSH directly before using Ansible.
ssh -i keys/rhce_ed25519 -o StrictHostKeyChecking=no rhce_node@127.0.0.1 'whoami'
The command should print rhce_node.
Testing SSH directly narrows the problem if Ansible later fails. If direct SSH cannot log in, fix the key, ownership, permissions, or inventory connection values before troubleshooting Ansible modules.
Validate Ansible Ping and Become
In this step, you will test Ansible connectivity and privilege escalation. The -b option means become, which asks Ansible to run the module with elevated privileges.
Before running commands in this step, return to the Ansible project directory. This keeps the commands stable even when LabEx runs each step separately.
cd /home/labex/project/rhce-ansible
Run the Ansible ping module over SSH.
ansible managed -m ansible.builtin.ping
This time the ping module is not using a local connection shortcut. Ansible should connect as rhce_node, transfer a small module, run it with Python, and return pong.
Run a command with privilege escalation. The command id -u prints 0 when it runs as root.
ansible managed -b -m ansible.builtin.command -a 'id -u'
The -b flag enables become for this command. A result containing 0 proves the managed user can escalate through the sudoers rule created for the lab.
Write a root-owned proof file using Ansible become.
ansible managed -b -m ansible.builtin.copy -a 'content=become_ready dest=/etc/rhce-ansible-become.txt mode=0644'
Writing under /etc requires administrative privileges, so this final command proves more than connectivity. It confirms Ansible can both connect over SSH and perform privileged system changes when requested.
Summary
You generated an SSH key pair, authorized it for a disposable managed user, configured SSH-based inventory access, and validated privilege escalation with Ansible become.
