Skip to main content

​
Configuration directory

Kensa’s configuration lives in the config/ directory (or /etc/kensa/ when installed via RPM). 
config/
├── defaults.yml          # Global variable defaults + framework overrides
├── conf.d/               # Site-specific overrides (alphabetical order)
│   └── 99-banner.yml     # Example: custom login banner
├── groups/               # Per-group variable overrides
│   └── databases.yml     # Overrides for the "databases" inventory group
└── hosts/                # Per-host variable overrides
    └── db01.example.com.yml

​
Variable precedence

Variables are resolved in this order (highest priority first):
  1. CLI --var KEY=VALUE
  2. Per-host config/hosts/<hostname>.yml
  3. Per-group config/groups/<group>.yml (last group wins)
  4. Site overrides config/conf.d/*.yml (alphabetical, later files override earlier)
  5. Framework defaults frameworks.<name> section in defaults.yml (when --framework is used)
  6. Global defaults variables section in defaults.yml

​
Customizing variables

Rules reference variables with {{ variable_name }} syntax. The defaults ship with values aligned to STIG (the most restrictive framework). Override them for your environment in config/conf.d/. Custom banner text (config/conf.d/99-banner.yml): 
banner_text: |
  WARNING: This system is the property of ACME Corp. Unauthorized
  access is prohibited. All activity is monitored and logged.
Relaxed password policy (config/conf.d/50-password.yml): 
pam_pwquality_minlen: 12
login_defs_pass_max_days: 180
pam_faillock_deny: 5
pam_faillock_unlock_time: 600
Per-host SSH timeout (config/hosts/jumpbox.example.com.yml): 
ssh_client_alive_interval: 300
ssh_client_alive_count_max: 3

​
Default variables

The full set of variables and their default values is documented in config/defaults.yml. Key variable groups: Password quality (pwquality.conf): pam_pwquality_minlen (15), pam_pwquality_minclass (4), pam_pwquality_difok (8), pam_pwquality_maxrepeat (3), pam_pwquality_dcredit (-1), pam_pwquality_ucredit (-1), pam_pwquality_lcredit (-1), pam_pwquality_ocredit (-1). Account lockout: pam_faillock_deny (3), pam_faillock_fail_interval (900), pam_faillock_unlock_time (0). Password aging (login.defs): login_defs_pass_max_days (60), login_defs_pass_min_days (1), login_defs_pass_warn_age (7), login_defs_umask (“077”), password_remember (5). SSH: ssh_client_alive_interval (900), ssh_client_alive_count_max (1), ssh_max_auth_tries (4), ssh_max_sessions (10), ssh_login_grace_time (60), ssh_approved_kex, ssh_approved_macs. Login banner: banner_text — displayed before authentication via /etc/issue and /etc/issue.net.

​
Framework-specific defaults

When you filter by framework (-f cis-rhel9-v2.0.0), Kensa automatically loads framework-specific variable values. This adjusts thresholds to match the framework’s requirements without manual overrides. For example, CIS allows pam_pwquality_minlen: 14 while STIG requires 15. Running with -f cis-rhel9-v2.0.0 uses the CIS value; running without a framework filter uses the STIG default. Framework defaults sit at priority level 5, below all site and host overrides but above the global defaults.

​
Inventory

Kensa accepts three formats for specifying targets.

​
Command-line hosts

kensa check -h 192.168.1.10,192.168.1.11 -u admin --sudo

​
INI inventory

Ansible-compatible format:
hosts.ini
[webservers]
web1.example.com
web2.example.com ansible_user=admin ansible_port=2222

[databases]
db1.example.com ansible_user=dba
db2.example.com ansible_user=dba

kensa check -i hosts.ini --sudo -w 4
kensa check -i hosts.ini --sudo -l webservers

​
YAML inventory

hosts.yml
all:
  - 192.168.1.10
  - 192.168.1.11

web_servers:
  - hostname: web01.example.com
    user: admin
    port: 2222
  - hostname: web02.example.com
    user: admin

db_servers:
  - hostname: db01.example.com
    user: dba
Per-host values in the inventory override CLI defaults. A host can appear in multiple groups.

​
Capability overrides

Kensa’s 22 capability probes determine which implementation variant runs for each rule. In rare cases, you may need to override a detection result: 
# Force sshd_config_d capability to false
kensa check -h 192.168.1.10 -u admin --sudo -C sshd_config_d=false

# Force multiple capabilities
kensa check -h 192.168.1.10 -u admin --sudo \
  -C authselect=true -C crypto_policies=false
Use -v (verbose) to see which capabilities were detected and which implementation was selected for each rule.

​
Parallel scanning

Use -w to scan multiple hosts concurrently: 
# Scan 8 hosts in parallel
kensa check -i production.ini --sudo -w 8
The worker count is capped at 50. Each worker opens an independent SSH connection. Choose a value that your SSH server and network can handle without connection throttling.

​
Troubleshooting

SSH connection failures: Run detect first to verify connectivity. Check that the SSH user has access and that --sudo is specified when needed. Unexpected SKIP results: A rule skips when the host’s platform or capabilities don’t match. Run detect to see the capability set and compare it against the rule’s when: gate. Use -v for per-rule implementation selection details. ERROR results: Usually indicate SSH timeouts, command failures, or unexpected output. Check error_detail in JSON or evidence output for the specific error message. Verbose mode: Add -v to any command to see capability probe results and per-rule implementation selection.