Linux

With the Linux Discovery integration, Clarity Transform enriches Linux device records over SSH with operating system details, installed packages and the host's own network connections. An ordinary shell account is sufficient; root is not required.

Where to find it

Go to Discover → Integrations, then select the Linux card. The card's category label is Operating System. The integration's page has the Endpoints and History tabs; Integrations describes the page, its grid and its row actions.

Why we do this

Host-level evidence originates at the endpoint rather than the network, so it reaches conversations the network may not see. Traffic between systems on the same segment, or between two virtual machines on the same host, never crosses a device capable of exporting flow data.

It is also the most direct evidence there is. The host's own connection table is direct evidence of who it is talking to, with no resolution step in between.

What we collect

• Operating system distribution and version
• Installed packages
• The host's own network connections

What it adds

Installed packages answer what is actually running on the machine, which no infrastructure source can reach. And the connection table adds conversations the network cannot see, including traffic between two machines on the same segment or the same hypervisor host.

What is deliberately not inferred

• No file contents and no application data. Package inventory, not data.
• Nothing is installed on the host. There is no agent.
• Nothing is changed. Every command is a read.
• A listening port is not a dependency, as on Windows.

What we require

An ordinary shell account over SSH. Root is not required.

• Interface: SSH
• Connectivity: the SSH port from Clarity to each host
• Account: an ordinary unprivileged user
• Optional: passwordless sudo limited to dmidecode only, where hardware serial numbers are wanted

Process attribution needs root, and its absence is quiet

Without root, connection data still arrives but the process names owning each connection are largely unavailable. Nothing fails and no error is raised. So if process-level attribution matters to the engagement it needs to be raised explicitly at provisioning time, rather than noticed as missing later.

Verification before handover

Run these as the system owner before handing the credential over, so a failed discovery run is never the first time anyone finds out.

1. Confirm SSH works as the account. Connect from the Clarity virtual machine to a sample host. Use password authentication, which is what a Clarity credential holds; what matters is that it is the Clarity host the connection comes from, since AllowUsers and firewall rules are frequently source-restricted.
2. Confirm the package inventory reads. Run the distribution's package query as the account. An ordinary user can do this on every supported distribution, so a failure here is usually a restricted shell rather than a permission.
3. Decide whether process attribution is wanted. List the host's connections as the account and look at the process column. Largely empty is the expected result without root. Settle deliberately whether that is acceptable, rather than discovering it in the output.

Configuring the endpoint

On the integration's Endpoints tab, select the add icon (Create New Integration Endpoints). The Create new entry form opens with these fields, in this order:

Field	Value
Name	A name for the endpoint
Credential	The stored credential for the shell account
Job Schedule	A five-field cron expression, for example 0 2 * * 0 (weekly). Package inventory changes on a patch cadence
Enabled	Ticked. The box is unticked when the form opens

The help texts: Credential "Credentials can be configured under Settings/Identity and Access Management/Credentials."; Job Schedule "Cron schedule – Use five fields: 〈mm〉 〈hh〉 〈day-of-month〉 〈month〉 〈weekday〉".

The Credential list offers the credentials stored under Settings → Identity & Access Management → Credentials, so create the credential there first.

The endpoint form has no End Point field, although the Endpoints grid has an End Point column.

No field is marked as required. Technology is set by the card and is hidden in the form. Select Save to create the endpoint, or Cancel to close the form. The edit icon opens the same fields as Edit entry.

Removing the access

Delete the account on the in-scope hosts, and remove the sudo entry if one was added. No agent was installed. Then, in Clarity, remove the endpoint (select its row on the Endpoints tab, then Remove selected) or clear its Enabled box, and remove the credential under Settings → Identity & Access Management → Credentials.

Troubleshooting

Symptom	Cause
Connections listed with no process names	Expected without root. The connection data arrives; process attribution largely does not. Raise it explicitly if it matters.
SSH fails from Clarity but works from a workstation	An AllowUsers directive or a source-restricted firewall rule. Test from the Clarity virtual machine specifically.
Package query fails	A restricted shell rather than a permission problem. An ordinary user can query packages on every supported distribution.
No hardware serial numbers	dmidecode needs the optional sudo entry. Nothing else is affected.