SSH Server Discovery Sensor
Discover_SSH inventories SSH servers over the network. It performs the client half of an SSH handshake against each target, records what the server offers and presents, and writes the result to the crypto inventory. Nothing is installed on the target and no account is required for the core of the scan.
Overview and what gets scanned
The sensor works in four phases, and how far a scan gets depends on what you give it.
| Phase | Needs | What it records |
|---|---|---|
| 1 — Banner and algorithms | Host only | Server banner, product and version, protocol version, and the four algorithm lists the server advertises: key exchange, host key, cipher and MAC |
| 2 — Host key | Host only | The server's host key for each algorithm family it offers, as a PEM public key with a SHA-256 fingerprint. An OpenSSH CA-signed host certificate is captured as a certificate alongside the key it contains |
| 3 — Authentication methods | Host and username | The authentication methods the server accepts, and whether it accepts none |
| 4 — Session checks | Host, username and credential | Whether the server honours a client-initiated rekey, and whether agent, X11 and TCP forwarding are permitted |
Phases 1 and 2 are everything an unauthenticated prober can see, and they are what most deployments run. Phases 3 and 4 add posture findings that need an account on the target.
What it produces. One protocol document per host carrying the algorithm lists and the session findings, plus one public key document per host key algorithm family — typically three to five documents per host. Where the server presents a CA-signed host certificate, a certificate document is written too, with the subject public key extracted from it as a separate key document.
What it does not produce. Private host key material is never read: it is not reachable over the protocol, and the sensor has no filesystem access to the target. Keys held in a user's authorized_keys are not part of this scan — those live on the host filesystem and are found by the file system sensor instead.
Prerequisites
Network access. The platform or the agent running the sensor must reach each target on its SSH port — 22 unless the target list says otherwise. The connection is outbound from CBOM Secure to the target; nothing connects back.
Credentials. None for phases 1 and 2. For phase 3, a username that exists on the target. For phase 4, that username and a working credential — either a password or a PEM private key.
Target-side prerequisites. None. The sensor speaks the protocol the server already offers and makes no configuration change.
Account rights. Where phases 3 and 4 are used, an ordinary unprivileged account is enough. The session checks ask the server what it permits; they do not need to do anything with the session. Create a dedicated account for this rather than reusing an administrator's.
Execution models. Supported by platform execution, remote execution on an agent and cloud execution. Off-grid bundles are supported, with the caveat that the bundle must run somewhere that can reach the targets — the sensor needs a live connection to the server it is interrogating.
Configuration fields
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
ExtName | string | Yes | Discover_SSH | The sensor name. Set for you by the form. |
Hosts | list | Yes | — | One entry per SSH server, written as host or host:port. Port defaults to 22. Note the capital H. |
timeout_seconds | integer | No | 10 | TCP connect and read timeout per host, between 1 and 120. |
username | string | No | — | Default username for any host that does not name its own. Setting it enables phase 3. |
credential | string | No | — | Default password or PEM private key. Setting it together with a username enables phase 4. |
The credential field holds either form. The sensor decides which by looking at the value: one beginning -----BEGIN is treated as a PEM private key, anything else as a password. Ed25519, ECDSA, RSA and DSA private keys are accepted. The value is stored encrypted and is never written to a log or returned by the API.
A minimal configuration, which runs phases 1 and 2:
ExtName: Discover_SSH
Hosts:
- bastion.corp.example.com
- build01.corp.example.com:2222
- 10.20.30.40A realistic configuration adding the posture checks:
ExtName: Discover_SSH
Hosts:
- bastion.corp.example.com
- jump02.corp.example.com
timeout_seconds: 15
username: cbom-probe
credential: "-----BEGIN OPENSSH PRIVATE KEY-----\n...\n-----END OPENSSH PRIVATE KEY-----"Scoping. The host list is explicit — there is no subnet expansion, and that is deliberate. A sensor that sweeps a range reaches hosts nobody meant to include, and on a network with intrusion detection a sweep of closed ports is what gets the scanning account disabled. Build the list from an existing inventory, or run one short scan to confirm reachability before enlarging it.
Execution modes
From the portal. Add the sensor to a discovery template, set the host list and any credentials, assign the template to a task, and run the task. The results appear in the crypto inventory under the target hosts.
On an agent. Include the sensor in a deployment to a host that sits closer to the targets than the platform does. The configuration is identical. This is the usual arrangement for a segmented network: the agent reaches the SSH servers, the platform reaches the agent.
Through the API. Deploy the task that carries the sensor and read the ingestion counts back. See the Scan and Discovery API reference for the request and response shapes.
Off-grid. Supported, provided the bundle runs on a host with network access to the targets. The results are collected as a file and imported.
Known limitations
| Limitation | Effect |
|---|---|
| SSH-1 servers | The banner is read and the protocol version recorded, but no key is extracted. An SSH-1 server yields a protocol document only. Finding one at all is itself the finding. |
| Post-quantum hybrid key exchange | Where a server offers only a hybrid key exchange the sensor does not implement, that key family is skipped rather than failing the host. The algorithm lists are still recorded, so the server's PQC readiness is still visible. |
| DSA host keys | The key size is detected, but no PEM is emitted. DSA is deprecated and the finding is the algorithm, not the key. |
| X11 forwarding detection | May report not permitted where the server requires an X11 display environment to answer. This is a limit of the probe, not a statement about the server. |
| Bastion and multi-hop targets | The sensor connects directly. A server reachable only through a jump host must be scanned by an agent on the far side. |
| Host key verification | The sensor trusts the key presented, by design — it is cataloguing host keys, not verifying them against a known-hosts file it has no reason to hold. |
Troubleshooting
Connection timed out. The port is filtered or the host is down. Confirm from the machine that runs the sensor, not from your workstation: nc -vz <host> 22. Raise timeout_seconds for a target behind a slow link before concluding it is unreachable.
Protocol document written, no key documents. The handshake reached the algorithm exchange and stopped. The usual cause is a server offering only key exchange algorithms the sensor does not implement. Check the recorded kexAlgorithms list on the protocol document.
No authentication methods recorded. Phase 3 did not run, which means no username was configured. The core scan is unaffected.
Session checks missing with a username set. Phase 4 needs a credential as well, and the credential must actually authenticate. A failed authentication leaves phases 1 to 3 intact and skips phase 4.
Authentication fails with a key that works from a terminal. The key must be pasted complete, including the -----BEGIN and -----END lines and the newlines between them. A key with a passphrase is not supported — use a separate unencrypted key issued for this purpose, held only in the platform.
The scan ran and the inventory is empty. Check the task's ingestion counts rather than the sensor. A scan that produced documents which did not reach the platform is an ingestion problem, not a discovery one.
Getting support
Collect the platform version, the sensor configuration with credentials removed, the task and template names, the relevant extract from the discovery log, and the output of ssh -vv <host> from the machine that ran the sensor. Redact hostnames only if your organisation requires it — they are usually what makes the log readable. Never include the credential itself; naming which credential was used is enough.