How to scan a Linux host for compliance

What you'll accomplish

Run a full read-only CIS/STIG compliance scan against a remote host over SSH, get a per-rule PASS/FAIL/SKIP verdict, and confirm afterward that nothing was installed or left behind on the target. Kensa runs from your workstation; the host you scan needs only SSH.

This is a read-only operation. check never changes the target, so it is safe to run against production.

Before you start

Kensa installed on your machine (workstation or bastion), from the package at hanalyx.com/download. Install the kensa and kensa-rules packages together; the rules install to a path Kensa finds on its own, so you scan with no -r flag.
SSH access to the target. Confirm a plain ssh admin@web01.example.com works first. Kensa uses your system's OpenSSH, so your keys, known_hosts, jump hosts, and SSH agent all behave exactly as your ssh config already defines them.
sudo on the target for privileged checks. Most hardening rules read privileged state, so you will almost always want --sudo.
Nothing on the target. No agent, no daemon, no package. That is the point of this guide, and the Verify step proves it.

Step 1: probe what the host can do

Start with detect. It is read-only and mutates nothing; it confirms Kensa can reach the host and prints the capability set it found (systemd, SELinux, auditd, apt, and so on).

kensa detect -H web01.example.com -u admin --sudo

If detect cannot connect, fix that before going further. Every other command uses the same transport, so a failure here is an SSH or sudo problem, not a Kensa one.

Step 2: run the compliance scan

check runs the rules and reports one row per rule as it completes, then a tally. It does not write to the transaction log by default; it only reads the host.

kensa check -H web01.example.com -u admin --sudo

Rows stream in scan order, then a summary. The shape looks like this (rule names and counts depend on your host):

PASS  ssh-max-auth-tries       Limit SSH maximum authentication attempts
FAIL  ssh-log-level            Set SSH log level to VERBOSE
SKIP  apparmor-profiles        (out of platform: rule targets ubuntu)
...
147 passed, 22 failed, 8 skipped

PASS / FAIL are the compliance verdict.
ERROR means the check could not be evaluated (a command failed to run), which is distinct from FAIL.
SKIP means the rule did not apply to this host (covered under "If it didn't work").

Narrow the run when you want a focused answer, by severity, framework, or category:

# Only critical and high-severity rules
kensa check -H web01.example.com -u admin --sudo -s critical -s high

# Only rules mapping a CIS RHEL 9 control
kensa check -H web01.example.com -u admin --sudo -f cis-rhel9

# A single control across whichever framework defines it
kensa check -H web01.example.com -u admin --sudo --control cis-rhel9:5.1.16

Tired of repeating -u admin --sudo and naming hosts one at a time? The companion guide How to configure Kensa once so daily scans need almost no flags sets up a config directory and a host inventory so these commands shrink to little more than a host name.

Verify

Two checks confirm the task succeeded.

1. The scan produced verdicts. You got streamed rows and a closing tally rather than a connection or sudo error. That is a completed scan.

2. Nothing was installed on the target. This is the claim worth proving. Ask the host directly whether Kensa is present:

ssh admin@web01.example.com 'command -v kensa || echo "kensa: not installed"'

Expected output:

kensa: not installed

Kensa left no binary, no package, and no daemon on the host. The scan ran entirely over the SSH session from your machine. That is the agentless model: the only footprint on the target is the SSH login itself, which your auth logs already record.

If it didn't work

sudo fails at connect time. By default --sudo runs sudo -n (non-interactive), which fails fast on a host whose sudoers policy requires a password. Supply one with --sudo-password (omit the value to be prompted on your terminal) or the KENSA_SUDO_PASSWORD environment variable. The password is fed over the SSH session's stdin, never placed on the command line or recorded in evidence. --sudo-password requires --sudo.
Every rule reports SKIP. Two gates cause it. Out of platform: Kensa compares each rule's target platform against the host's detected OS and skips rules that do not apply; the shipped corpus targets RHEL, so scanning an Ubuntu host can skip nearly everything. That is faithful behavior, not a fault. Capability mismatch: a rule's implementation needs a capability the host lacks. Run kensa detect to see the detected set, and override a wrong probe with -C KEY=VALUE (for example -C selinux=true).
"No rules found." You installed kensa without kensa-rules, so the default rules directory is empty. Install kensa-rules, or point at a rules directory explicitly with --rules-dir <path> on every command.
Host-key prompt or "host key changed." Kensa trusts the host key on first use and records it. If a host was legitimately reinstalled, remove its stale known_hosts entry and reconnect to re-pin. For a security-sensitive run, add --strict-host-keys to verify the key and reject an unknown or changed one.

How to configure Kensa once so daily scans need almost no flags — set up a config directory, policy variables, and an inventory so the commands above need only a host.
How to remediate one control and roll it back — the next step, when you want Kensa to fix a FAIL and be able to undo it.
How to see what a host supports before scanning — a deeper look at kensa detect and capability overrides.

For the full command reference, see the documentation.