ProHoster > Блог > Новини інтернету > Реліз OpenSSH 8.7

Реліз OpenSSH 8.7

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

Основні зміни:

  • У scp доданий експериментальний режим передачі з використанням протоколу SFTP замість традиційно застосовуваного протоколу SCP/RCP. У SFTP застосовуються більш передбачувані методи обробки імен та не використовується обробка glob-шаблонів через shell на стороні іншого хоста, що створює проблеми з безпекою. Для включення SFTP у scp запропоновано прапор "-s", але в майбутньому планується перейти на цей протокол за промовчанням.
  • У sftp-server реалізовано розширення протоколу SFTP для розкриття шляхів ~/ та ~user/, що необхідно для scp.
  • В утиліті scp змінено поведінку під час копіювання файлів між двома віддаленими хостами (наприклад, «scp host-a:/path host-b:»), яке тепер за замовчуванням здійснюється через проміжний локальний хост, як за вказівкою прапора «-3». Зазначений підхід дозволяє уникнути передачі зайвих облікових даних на перший хост та потрійної інтерпретації імен файлів у shell (на стороні джерела, приймача та локальної системи), а також при використанні SFTP дозволяє використовувати всі методи автентифікації при зверненні до віддалених хостів, а не лише неінтерактивні методи . Для відновлення старої поведінки додано опцію "-R".
  • У ssh додано налаштування ForkAfterAuthentication, яке відповідає прапору «-f».
  • У ssh додано налаштування StdinNull, яке відповідає прапору «-n».
  • У ssh додано налаштування SessionType, через яке можна встановити режими, що відповідають прапорам "-N" (без сеансу) та "-s" (subsystem).
  • У ssh-keygen у файлах з ключами можна вказувати інтервал дії ключа.
  • У ssh-keygen доданий прапор "-Oprint-pubkey" для виведення повного відкритого ключа у складі підпису sshsig.
  • У ssh і sshd, як клієнт, так і сервер, переведені на використання більш строгого парсера конфігураційного файлу, в якому використовуються схожі на shell правила обробки лапок, пробілів і escape-символів. Новий парсер також не пропускає раніше наявні припущення, такі як пропуск аргументів в опціях (наприклад, тепер не можна залишати порожньою директиву DenyUsers), незакриті лапки та вказівку кількох символів "=".
  • При використанні DNS-записів SSHFP при верифікації ключів, ssh тепер перевіряє всі записи, що збіглися, а не тільки містять певний тип цифрового підпису.
  • У ssh-keygen при генерації ключа FIDO із зазначенням опції -Ochallenge для хешування тепер використовується вбудований прошарок, а не засоби libfido2, що дозволяє використовувати challenge-послідовність, розміром більше або менше 32 байт.
  • У sshd під час обробки директиви environment=»…» у файлах authorized_keys тепер приймається перший збіг і діє обмеження в 1024 імен змінних оточення.

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

Для перевірки застосування ssh-rsa у своїх системах можна спробувати підключитися по ssh з опцією "-oHostKeyAlgorithms=-ssh-rsa". При цьому відключення за замовчуванням цифрових підписів ssh-rsa не означає повну відмову від використання RSA-ключів, оскільки крім SHA-1 протокол SSH допускає застосування інших алгоритмів обчислення хешів. Зокрема, крім «ssh-rsa» залишиться можливість використання зв'язок «rsa-sha2-256» (RSA/SHA256) та «rsa-sha2-512» (RSA/SHA512).

Для згладжування переходу на нові алгоритми в OpenSSH раніше за умовчанням було включено налаштування UpdateHostKeys, яке дозволяє автоматично перевести клієнтів на більш надійні алгоритми. За допомогою зазначеної настройки включається спеціальне розширення протоколу «[захищено електронною поштою]», що дозволяє серверу після проходження автентифікації інформувати клієнта про всі доступні ключі хоста. Клієнт може відобразити ці ключі у файлі ~/.ssh/known_hosts, що дозволяє організувати оновлення ключів хоста і спрощує зміну ключів на сервері.

Використання UpdateHostKeys обмежено кількома застереженнями, які в майбутньому можуть бути скасовані: ключ повинен згадуватися в UserKnownHostsFile і не використовуватись у GlobalKnownHostsFile; ключ повинен бути присутнім лише під одним ім'ям; не повинен застосовуватись сертифікат хостового ключа; у known_hosts не повинно застосовуватись масок на ім'я хоста; має бути вимкнено налаштування VerifyHostKeyDNS; має бути активований параметр UserKnownHostsFile.

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

Джерело: opennet.ru

Додати коментар або відгук