SSH-based OS identification

30 of enodia’s products — every Linux distribution, FreeBSD, OpenBSD, NetBSD, macOS, Oracle Solaris, OPNsense, and legacy CentOS — are identified over SSH, not HTTP. This page explains the shared mechanism once; each OS’s own page (linked from Supported products) only states its specific product: value, the exact identity field it matches on, and its lifecycle resolver.

How it works

One SSH connection, one command, one disconnect — this is not a general-purpose remote-exec client, just enough to read a single identity fact:

• 23 products read /etc/os-release (the systemd-standardized identity file every modern Linux distribution ships, plus FreeBSD’s own /var/run/os-release, generated dynamically at boot in the same KEY=VALUE shape) and check its ID field.
• 2 products (OpenBSD, NetBSD) have no os-release-equivalent file at all — uname -sr is the identity source instead ("<kernel name> <release>", e.g. "OpenBSD 7.9").
• 5 more (Astra Linux, legacy CentOS, macOS, OPNsense, Oracle Solaris) read a distinct, product-specific identity file or command each — see their own pages.

product: is always declared explicitly and verified against the real identity field, never guessed from the response (the same principle the Atlassian probes use for their manifest’s <typeId>) — pointing a Debian host at product: ubuntu is a real config mistake that fails loudly rather than getting recorded as a wrong fact.

Configuration

targets:
  - id: web-01
    product: debian          # or any other OS product — see its own page
    address: web-01.example.com
    credentials: linux-host-ssh
    tls:
      pin_sha256:
        - "AB:CD:...:EF"      # sha256 of the host's SSH key

credentials:
  linux-host-ssh:
    kind: ssh-key
    username: enodia-ro
    private_key_file: /etc/enodia/ssh/id_ed25519

Port defaults to 22 when address doesn’t carry one — no scheme, same as MySQL/Redis (a bare host:port, not a URL).

Authentication — required

Every probe in this family has Required: true — there is no anonymous path to an OS’s identity, unlike most of the HTTP-based products. Two credential shapes work, exactly like any SSH client:

• kind: password — username + password
• kind: ssh-key — username + private_key_file (+ passphrase if the key is encrypted)

See Configuration → Credentials for the full field reference.

Host key verification

Reuses the same tls: block HTTPS probes use for certificate pinning — tls.pin_sha256 holds the hex SHA-256 of the SSH host key’s own wire encoding (not a TLS certificate), and tls.insecure: true is the same last-resort opt-out, warned about the same way. With neither set, the connection is refused before a single credential is sent. See Configuration → SSH host key verification for the full explanation.

Recorded fields

Every probe in this family records:

• version — from VERSION_ID (os-release family) or the kernel release (uname family)
• extra.hostKeyVerified — "true"/"false", whether tls.pin_sha256 actually matched (surfaces the same way TLSVerified does for HTTPS targets — a fleet-wide audit of which SSH targets are pinned)

A target with no matching file or command fails loudly

Both cat /etc/os-release on a host that doesn’t have one and uname -sr reporting the wrong kernel name come back as a clear “not this product” error rather than a generic connection failure — the SSH session itself succeeded, the identity check is what failed.