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

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

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

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

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

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)
extra.hostKeyVerified — "true"/"false", действительно ли совпал tls.pin_sha256 (работает так же, как TLSVerified у HTTPS-таргетов — аудит по всему флоту, какие SSH-таргеты закреплены)

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

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