Skip to Content

Troubleshooting

Quick reference

IssueSolution
SSH locked out after hardeningUse VM/cloud console; restore ~<user>/.ssh/authorized_keys from backup (.backup suffix)
Account lockedUse VM/cloud console (SSH fails when locked); run faillock --user <user> --reset
GRUB password errorEnsure grub2_password in vault.yml is the plaintext password - the role hashes it at runtime
ed25519 key rejected after hardeningSwitch to an RSA or ECDSA key (FIPS requirement)
401 Unauthorized on depot packagesCheck ciq_depot_username / ciq_depot_token in the vault
ERROR! the role ... was not foundRun commands from inside your scaffolded working directory (e.g. ~/ciq-lockdown) so Ansible auto-loads ansible.cfg, and confirm playbooks are invoked by FQCN, not a filesystem path
Vault decryption failedVerify .vault_pass contents match the password used to encrypt vault.yml

SSH lockout

If SSH stops working after hardening:

  1. Use VM/cloud console access.
  2. Check /etc/ssh/sshd_config.d/99-ciq-emergency.conf.
  3. Restore ~<user>/.ssh/authorized_keys from backup (.backup suffix).
  4. Restore from snapshot if needed.

To prevent lockout on iterative runs, place hosts in the testing inventory group - it disables the SSH and PAM rules that can cut off access. See Configuration.

Account lockout

If an account is locked after hardening, SSH will not work for it. Access the target via VM/cloud console and run this command directly on the target:

faillock --user <user> --reset

GRUB bootloader password skipped

WARNING: RHEL-09-212010 (GRUB2 bootloader password) will be SKIPPED -- set grub2_password and grub2_username in vault.yml to enable it.

The GRUB bootloader password control (RHEL-09-212010) doesn't hard-fail when unconfigured - it skips cleanly with this warning, leaving that one control unremediated. Set the plaintext password in the vault; the role generates the PBKDF2 hash and writes /boot/grub2/user.cfg itself at runtime, so you don't need to run grub2-mkpasswd-pbkdf2 by hand:

# In inventory/group_vars/all/vault.yml grub2_password: "your-plaintext-password"

grub2_username defaults to bootadmin and doesn't need to be set unless you want a different GRUB admin username.

SSH connection issues

"Please login as user X rather than root" / "Permission denied": By default, Rocky Linux does not allow root SSH logins. Configure a non-root user with sudo elevation:

# inventory/hosts.yml all: vars: ansible_user: <user> # e.g. 'rocky' for cloud images ansible_become: true ansible_become_method: sudo ansible_become_pass: "{{ vault_ansible_become_pass }}" ansible_ssh_private_key_file: ~/.ssh/id_rsa_rlch

Run the playbook and then test connectivity:

# Direct SSH ssh -i ~/.ssh/id_rsa_rlch <user>@<target-ip> "hostname" # Ansible ansible all -m ping

Empty inventory / no hosts found

[WARNING]: provided hosts list is empty, only localhost is available

Verify your inventory has hosts and Ansible is reading the right file:

grep "ansible_host:" inventory/hosts.yml ansible-inventory --list

If ansible-inventory shows nothing, confirm you're running from inside your scaffolded working directory so Ansible auto-loads ansible.cfg.

authselect custom profile missing

failed: [host] => { "msg": "Path /etc/authselect/custom/rlch9-hardened/password-auth does not exist!" }

CIS rules 5.3.3.x expect a custom authselect profile created by CIS rules 5.3.2.x. If the 5.3.2.x rules were disabled or skipped, the profile won't exist. Enable the prerequisite rules:

rhel9cis_rule_5_3_2_1: true rhel9cis_rule_5_3_2_2: true rhel9cis_rule_5_3_2_3: true rhel9cis_rule_5_3_2_4: true

Or run the STIG profile instead - STIG uses the vendor authselect profile.

Useful runtime flags

Run from inside your scaffolded working directory:

# Preview without changing anything ansible-playbook ctrliq.rlch9_lockdown.rlch9_combined --check --diff # Skip the automatic reboot during iterative testing ansible-playbook ctrliq.rlch9_lockdown.rlch9_combined --skip-tags auto_reboot # List which tasks would run ansible-playbook ctrliq.rlch9_lockdown.rlch9_combined --list-tasks

Getting help

If an issue persists, contact CIQ Support with the playbook output and the contents of /var/log/ciq-lockdown/ from the target system.