Agentless SSH host inventory

"Agentless" is a word vulnerability scanners throw around a lot. What it actually means in practice — and what tradeoffs it comes with — is more interesting than the marketing usually admits.

What "agentless" really means

An agent-based scanner installs a process on every host it monitors. The agent does the heavy lifting locally and reports results upstream.

An agentless scanner connects to each host the same way you do — over SSH — runs read-only commands, parses the output, and walks away. Nothing is installed. Nothing keeps running. The target host never knows the scanner exists outside the normal SSH log lines.

What gets read

A typical agentless inventory reads a small, well-known set of files and queries the package manager. The exact set varies by distro, but generally:

• OS identity (distro, version, codename).
• Kernel version.
• Installed packages and versions.
• SSH server configuration, where readable.
• The connecting user's authorised SSH keys.

That's enough to derive: which packages have known CVEs, whether SSH posture is hardened, and whether anyone has authorised keys they shouldn't.

The case for agentless

• Nothing to install. Add a host to your inventory by adding it to ~/.ssh/config. There is no second step.
• Nothing to maintain. Agents need updates of their own. An agentless scan just talks to whatever's already on the host.
• Nothing to break. An agent that crashes or hangs takes the visibility with it. SSH either works or it obviously doesn't.
• Nothing to attack. An always-on agent is a process worth exploiting. Read-only SSH commands aren't.
• Works on rented infrastructure. VPSes, embedded devices, appliance-style boxes, and friend-of-friend Pis all support SSH. Many won't tolerate an agent.

The case against agentless

• Less data. Real-time telemetry — process events, file changes, network connections — needs an agent. Agentless gives you the snapshot, not the stream.
• Network round-trips. Each scan opens a connection per host. Across hundreds of hosts on a slow link, that adds up. Fine for homelab and small-fleet use; less suited to thousand-host fleets.
• Permissions. Some files (notably sshd_config) usually need root. The connecting user often can't read everything.
• Stale-state risk. An agentless snapshot is correct as of the moment of the scan. If a vulnerable package gets installed between scans, you'll catch it on the next nightly run, not in real time.

Where agentless fits the homelab perfectly

Homelab fleets are small (single digits to tens of hosts), the operator already has SSH access to everything, and real-time telemetry is overkill. The bottleneck isn't "we don't have second- by-second data" — it's "no one's looking until something breaks."

Nightly agentless scans paired with a diff-from-yesterday view cover that gap. Every morning you see what changed. Most days that's nothing. The day a CVE lands on a package you have installed, you see it before lunch.

What Noxen does

Noxen runs on your Mac. You point it at your hosts (it imports from ~/.ssh/config automatically). It connects via SSH, reads the inventory, matches it against a daily-refreshed CVE feed, and produces a nightly report.

No agent on the targets. No "install Noxen on each box." No always-on listener. Add and remove hosts in a single click. If you can SSH into a box, Noxen can audit it.