SSH-пробы для определения ОС

31 продукт enodia — все дистрибутивы Linux, FreeBSD, OpenBSD, NetBSD, macOS, Oracle Solaris, OPNsense, pfSense и устаревший CentOS — определяются через SSH, а не HTTP. На этой странице механизм объясняется один раз; собственная страница каждой ОС (со ссылкой из Поддерживаемых продуктов) указывает только конкретное значение product:, точное поле идентичности, по которому идёт сверка, и резолвер жизненного цикла.

Как это работает

Одно SSH-соединение, одна команда, одно отключение — это не универсальный клиент удалённого выполнения, а ровно то, что нужно, чтобы прочитать нужные факты об идентичности:

21 продукт читают /etc/os-release (файл идентичности, стандартизированный systemd и присутствующий в любом современном дистрибутиве Linux, плюс собственный /var/run/os-release у FreeBSD, генерируемый динамически при загрузке в той же форме КЛЮЧ=ЗНАЧЕНИЕ) и сверяют его поле ID — общий, типовой механизм (osReleaseFamilyProbe).
Ещё 2 (Debian, Ubuntu) тоже читают /etc/os-release, но через собственную, отдельную пробу, а не через типовой механизм выше — у обоих дистрибутивов VERSION_ID неточен (у Debian он вообще никогда не несёт point-релиз; у Ubuntu фиксируется на первом релизе и никогда не отражает более поздний point-релиз), поэтому каждый читает ещё немного дальше ради реальной точности: Debian дополнительно сверяет /etc/debian_version, Ubuntu предпочитает поле VERSION того же файла, когда оно точнее. За подробностями — на их собственные страницы.
2 продукта (OpenBSD, NetBSD) вообще не имеют аналога os-release — источником идентичности вместо него служит uname -sr ("<имя ядра> <релиз>", например "OpenBSD 7.9").
Ещё 6 (Astra Linux, устаревший CentOS, macOS, OPNsense, pfSense, Oracle Solaris) читают свой собственный, специфичный для продукта файл или команду идентичности — см. их собственные страницы.

Начиная с 2.1, десять из них — Debian, Ubuntu, Linux Mint, RHEL, Rocky Linux, AlmaLinux, Oracle Linux, Astra Linux, РЕД ОС и Alpine — в той же команде ещё перечисляют установленные пакеты и читают работающее ядро (uname -r/-m/-v), для сопоставления с CVE по пакетам. Список пакетов сохраняется в наблюдении, поэтому инвентарь таких хостов больше — десятки КБ на хост.

product: всегда указывается явно и сверяется с реальным полем идентичности, а не угадывается по ответу — тот же принцип, что и у проб Atlassian для <typeId> из manifest — указать product: ubuntu для хоста с Debian — это реальная ошибка конфигурации, которая громко откажет, а не тихо запишется как неверный факт.

Конфигурация

targets:
  - id: web-01
    product: debian          # или любой другой продукт-ОС — см. его страницу
    address: web-01.example.com
    credentials: linux-host-ssh
    tls:
      pin_sha256:
        - "AB:CD:...:EF"      # sha256 SSH-ключа хоста

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

Порт по умолчанию — 22, если в address он не указан — без схемы, как у MySQL/Redis (обычный host:port, не URL).

Аутентификация — обязательна

У каждой пробы в этом семействе Required: true — анонимного пути к идентичности ОС не существует, в отличие от большинства продуктов на HTTP. Работают два вида credential, как и у любого SSH-клиента:

kind: password — username + password
kind: ssh-key — username + private_key_file (+ passphrase, если ключ зашифрован)

Полный список полей — в Конфигурации → Credentials.

Проверка ключа хоста

Используется тот же блок tls:, что и у HTTPS-проб для закрепления сертификата — tls.pin_sha256 хранит hex SHA-256 самого SSH-ключа хоста в его wire-кодировке (не TLS-сертификата), а tls.insecure: true — тот же последний резерв, с тем же предупреждением. Если не указаны ни pin_sha256, ни insecure: true, соединение отклоняется ещё до отправки хоть одного credential. Полное объяснение — в Конфигурации → Проверка ключа хоста SSH.

Записываемые поля

Каждая проба в этом семействе записывает:

version — из VERSION_ID (семейство os-release) или релиза ядра (семейство uname); Debian и Ubuntu читают дальше ради точного point-релиза, которого одного VERSION_ID не несёт — см. их собственные страницы
extra.hostKeyVerified — "true"/"false", действительно ли совпал tls.pin_sha256 (работает так же, как TLSVerified у HTTPS-таргетов — аудит по всему флоту, какие SSH-таргеты закреплены)

Таргет без подходящего файла или команды громко откажет

И cat /etc/os-release на хосте, где такого файла нет, и uname -sr, сообщающий не то имя ядра, возвращаются как понятная ошибка «не тот продукт», а не как обобщённый сбой соединения — само SSH-соединение установилось успешно, отказала именно проверка идентичности.