Реліз OpenSSH 8.2 c підтримкою токенів двофакторної аутентифікації FIDO/U2F

Після чотирьох місяців розробки представлений реліз OpenSSH 8.2, відкритої реалізації клієнта та сервера для роботи за протоколами SSH 2.0 та SFTP.

Ключовим покращенням у випуску OpenSSH 8.2 стала можливість використання двофакторної автентифікації за допомогою пристроїв, що підтримують протокол U2F, що розвивається альянсом FIDO. U2F дозволяє створювати недорогі апаратні токени для підтвердження фізичної присутності користувача, взаємодія з якими здійснюється через USB, Bluetooth чи NFC. Подібні пристрої просуваються як засіб двофакторної аутентифікації на сайтах, вже підтримуються основними браузерами і випускаються різними виробниками, включаючи Yubico, Feitian, Thetis і Kensington.

Для взаємодії з пристроями, що підтверджують присутність користувача, в OpenSSH додані нові типи ключів ecdsa-sk і ed25519-sk, в яких використовуються алгоритми цифрового підпису ECDSA і Ed25519, у поєднанні з хеш SHA-256. Процедури взаємодії з токенами винесені до проміжної бібліотеки, яка завантажується за аналогією з бібліотекою для підтримки PKCS#11 та є обв'язкою над бібліотекою libfido2, що надає засоби для комунікації з токенами поверх USB (підтримується протоколи FIDO U2F/CTAP 1 та FIDO 2.0/CTAP 2). Підготовлена ​​розробниками OpenSSH проміжна бібліотека libsk-libfido2 включено в основний склад libfido2, як і HID-драйвер для OpenBSD.

Для аутентифікації та генерації ключа необхідно вказати параметр «SecurityKeyProvider» або виставити змінну оточення SSH_SK_PROVIDER, вказавши шлях до зовнішньої бібліотеки libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). Можливе складання openssh із вбудованою підтримкою бібліотеки-прошарку (—with-security-key-builtin), у цьому випадку необхідно виставити параметр «SecurityKeyProvider=internal».
Далі потрібно запустити ssh-keygen -t ecdsa-sk або, якщо ключі вже створені і налаштовані, підключитися до сервера за допомогою ssh. При запуску ssh-keygen створена пара ключів буде збережена в ~/.ssh/id_ecdsa_sk і може використовуватися аналогічно іншим ключам.

Відкритий ключ (id_ecdsa_sk.pub) слід скопіювати на сервер файл authorized_keys. На стороні сервера лише перевіряється цифровий підпис, а взаємодія з токенами виробляється за клієнта (на сервері не потрібно встановлювати libsk-libfido2, але сервер повинен підтримувати тип ключів «ecdsa-sk»). Згенерований закритий ключ (id_ecdsa_sk) по суті є дескриптором ключа, що створює реальний ключ тільки в поєднанні з секретною послідовністю, що зберігається на стороні токена U2F. У разі попадання ключа id_ecdsa_sk в руки атакуючого, для проходження аутентифікації йому також потрібно отримати доступ до апаратного токену, без якого закритий ключ непотрібний у файлі id_ecdsa_sk.

Крім того, за умовчанням при виконанні будь-яких операцій з ключами (як при генерації, так і при аутентифікації) потрібно локальне підтвердження фізичної присутності користувача, наприклад, пропонується торкнутися сенсора на токені, що ускладнює проведення віддалених атак на системи з підключеним токеном. Як ще один рубеж захисту на етапі запуску ssh-keygen також може бути заданий пароль для доступу до файлу з ключем.

У новій версії OpenSSH також оголошено про майбутній переведення в розряд застарілих алгоритмів, які використовують хеші SHA-1 у зв'язку з підвищенням ефективності колізійних атак із заданим префіксом (вартість підбору колізії оцінюється приблизно в 45 тисяч доларів). В одному з найближчих випусків планують відключити за замовчуванням можливість використання алгоритму цифрових підписів за відкритим ключем «ssh-rsa», який згадується в оригінальному RFC для протоколу SSH і залишається на практиці широко поширеним (для перевірки застосування ssh-rsa у своїх системах можна спробувати підключитися. по ssh з опцією "-oHostKeyAlgorithms=-ssh-rsa").

Для згладжування переходу на нові алгоритми OpenSSH в одному з наступних випусків за замовчуванням буде включено налаштування UpdateHostKeys, яке дозволить автоматично перевести клієнтів на більш надійні алгоритми. Серед рекомендованих для міграції алгоритмів згадані rsa-sha2-256/512 на базі RFC8332 RSA SHA-2 (підтримується з OpenSSH 7.2 та використовується за замовчуванням), ssh-ed25519 (підтримується з OpenSSH 6.5) та ecdsa2/256 з урахуванням RFC384 ECDSA (підтримується з OpenSSH 521).

У версії OpenSSH 8.2 можливість підключення з використанням «ssh-rsa» поки що залишена, але цей алгоритм вилучено зі списку CASignatureAlgorithms, що визначає алгоритми, допустимі для цифрового підпису нових сертифікатів. Аналогічно з алгрітмів обміну ключами, що підтримуються за умовчанням, видалений алгоритм diffie-hellman-group14-sha1. Зазначається, що використання SHA-1 у сертифікатах пов'язане з додатковим ризиком, оскільки атакуючий має необмежений час на пошук колізії для існуючого сертифіката, тоді як час атаки на хостові ключі обмежені таймом підключення (LoginGraceTime).

При виконанні ssh-keygen тепер за замовчуванням застосовується алгоритм rsa-sha2-512, який підтримується починаючи з OpenSSH 7.2, що може створити проблеми із сумісністю при спробі обробки сертифікатів, завірених у OpenSSH 8.2, на системах зі старими випусками OpenSSH (для обходу проблеми при формуванні підпису можна явно вказати "ssh-keygen-t ssh-rsa" або використовувати алгоритми ecdsa-sha2-nistp256/384/521, що підтримуються з OpenSSH 5.7).

Інші зміни:

• У sshd_config додано директиву Include, що дозволяє включати вміст інших файлів у поточну позицію конфігураційного файлу (при заданні імені файлу допускається застосування glob-масок);
• У ssh-keygen додана опція "no-touch-required", що відключає необхідність фізичного підтвердження доступу до токену при генерації ключа;
• У sshd_config додано директиву PubkeyAuthOptions, що поєднує різні опції, пов'язані з автентифікацією за відкритими ключами. В даний час підтримується лише прапор "no-touch-required" для пропуску перевірки фізичної присутності при авторизації за допомогою токена. За аналогією до файлу authorized_keys додано опцію «no-touch-required»;
• У ssh-keygen додано опцію "-O write-attestation=/path", що дозволяє записати додаткові атестаційні сертифікати FIDO при генерації ключів. OpenSSH поки не використовує дані сертифікати, але вони надалі можуть бути використані для перевірки розміщення ключа в апаратному сховищі, що заслуговує на довіру;
• У налаштуваннях ssh і sshd через директиву IPQoS тепер можливе встановлення режиму пріоритезації трафіку LE DSCP (Lower-Effort Per-Hop Behavior);
• У ssh при встановленні значення «AddKeysToAgent=yes», якщо ключ не містить поля з коментарем, він буде доданий до ssh-agent з зазначенням як коментар шляху до ключа. У
  ssh-keygen і ssh-agent як коментарі в ключі також тепер використовуються мітки PKCS#11 та ім'я суб'єкта X.509 замість шляху до бібліотеки;

• У ssh-keygen додано можливість експорту PEM для ключів DSA та ECDSA;
• Доданий новий файл ssh-sk-helper, що використовується для ізоляції бібліотеки доступу до токенів FIDO/U2F;
• У ssh і sshd додана збірна опція «with-zlib» для компіляції з підтримкою бібліотеки zlib;
• Відповідно до вимог RFC4253 у виведеному при підключенні банері забезпечений показ попередження про блокування доступу через перевищення лімітів MaxStartups. Для спрощення діагностики в заголовку процесу sshd, видимому під час використання утиліти ps, забезпечено відображення числа аутентифікованих на даний момент з'єднань та стан ліміту MaxStartups;
• У ssh і ssh-agent при виклику програми для виведення на екран запрошення, що задається через $SSH_ASKPASS, тепер додатково передається прапор з типом запрошення: confirm - діалог підтвердження (yes/no), none - інформаційне повідомлення, blank - Запит пароля;
• У ssh-keygen додано нову операцію з цифровими підписами «find-principals» для пошуку у файлі allowed-signers користувача, пов'язаного із зазначеним цифровим підписом;
• Покращена підтримка ізоляції процесу sshd в Linux за допомогою механізму seccomp: заборонені системні виклики IPC, дозволені clock_gettime64(), clock_nanosleep_time64 та clock_nanosleep().

Джерело: opennet.ru