Ідентифікація ОС через SSH

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

Як це працює

Одне SSH-зʼєднання, одна команда, одне відʼєднання — це не універсальний клієнт віддаленого виконання, а рівно стільки, скільки потрібно, щоб прочитати один факт ідентичності:

21 продукт читає /etc/os-release (стандартизований systemd файл ідентичності, який постачає кожен сучасний дистрибутив Linux, а також власний /var/run/os-release у FreeBSD, що генерується динамічно під час завантаження в тому самому форматі KEY=VALUE) і перевіряє його поле ID — спільний узагальнений механізм (osReleaseFamilyProbe).
Ще 2 (Debian, Ubuntu) також читають /etc/os-release, але через власну окрему пробу, а не через узагальнений механізм вище — обидва дистрибутиви залишають VERSION_ID неточним (у Debian він ніколи не містить точкового релізу; в Ubuntu він фіксується на першому релізі й ніколи не відображає пізніший точковий реліз), тож кожна проба читає далі, щоб отримати справжню версію: Debian додатково звіряє /etc/debian_version, Ubuntu віддає перевагу полю VERSION того самого файлу, коли воно точніше. Чому саме так — див. на їхніх власних сторінках.
2 продукти (OpenBSD, NetBSD) взагалі не мають файлу, еквівалентного os-release, — джерелом ідентичності натомість є uname -sr ("<kernel name> <release>", наприклад "OpenBSD 7.9").
Ще 5 (Astra Linux, застарілий CentOS, macOS, OPNsense, Oracle Solaris) читають кожен свій окремий, специфічний для продукту файл ідентичності або команду — див. їхні власні сторінки.

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

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

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. Працюють два види облікових даних, точно як у будь-якому SSH-клієнті:

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

Повний довідник полів див. у розділі Конфігурація → Облікові дані.

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

Використовує той самий блок tls:, що й HTTPS-проби для закріплення сертифікатів, — tls.pin_sha256 містить шістнадцятковий SHA-256 від власного wire-кодування SSH-ключа хоста (а не TLS-сертифіката), а tls.insecure: true — це та сама крайня відмова від перевірки, із таким самим попередженням. Якщо не задано жодного з них, зʼєднання відхиляється ще до надсилання будь-яких облікових даних. Повне пояснення див. у розділі Конфігурація → Перевірка ключа хоста SSH.

Записувані поля

Кожна проба цього сімейства записує:

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

Ціль без відповідного файлу чи команди завершується явною помилкою

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