Пасля пяці месяцаў распрацоўкі прадстаўлены рэліз OpenSSH 8.5, адчыненай рэалізацыі кліента і сервера для працы па пратаколах SSH 2.0 і SFTP.
Распрацоўнікі 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 8.5 па змаўчанні ўключана настройка 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).
Іншыя змены:
- Змены, звязаныя з бяспекай:
- У ssh-agent ухіленая ўразлівасць, выкліканая паўторным вызваленнем ужо вызваленай вобласці памяці (double-free). Праблема выяўляецца з выпуску OpenSSH 8.2 і патэнцыйна можа быць эксплуатаваная пры наяўнасці ў атакавалага доступу да сокету ssh-agent на лакальнай сістэме. Эксплуатацыю ўскладняе тое, што доступ да сокета маюць толькі root і зыходны карыстач. Найбольш верагодным сцэнарам атакі з'яўляецца перанакіраванне агента на ўліковы запіс, які падкантрольны зламысніку, альбо на хост, на якім у зламысніка ёсць root-доступ.
- У sshd дададзена абарона ад перадачы вельмі вялікіх параметраў з імем карыстальніка ў падсістэму PAM, што дазваляе блакаваць уразлівасці ў сістэмных модулях PAM (Pluggable Authentication Module). Напрыклад, змена дазваляе прадухіліць выкарыстанне sshd у якасці вектара для эксплуатацыі нядаўна выяўленай root-уразлівасці ў Solaris (CVE-2020-14871).
- Змены, якія патэнцыйна парушаюць сумяшчальнасць:
- В ssh и sshd переработан экспериментальный метод обмена ключами, стойкий к подбору на квантовом компьютере. Квантовые компьютеры кардинально быстрее решают задачу разложения натурального числа на простые множители, которая лежит в основе современных асимметричных алгоритмов шифрования и эффективно не решаема на классических процессорах. Используемый метод основан на алгоритме NTRU Prime, разработанном для постквантумных криптосистем, и методе обмена ключами на базе эллиптических кривых X25519. Вместо [электронная пошта абаронена] метод теперь идентифицируется как [электронная пошта абаронена] (алгарытм sntrup4591761 заменены на sntrup761).
- У ssh і sshd зменены парадак анансавання падтрымліваемых алгарытмаў лічбавых подпісаў. Першым зараз прапануецца ED25519 замест ECDSA.
- У ssh і sshd усталёўка параметраў якасці абслугоўвання TOS/DSCP для інтэрактыўных сеансаў зараз вырабляецца да ўсталёўкі TCP-злучэнні.
- У ssh і sshd спынена падтрымка шыфра [электронная пошта абаронена], які ідэнтычны aes256-cbc і выкарыстоўваўся да зацвярджэння RFC-4253.
- Па змаўчанні адключаны параметр CheckHostIP, карысць ад якога малаважная, але выкарыстанне істотна ўскладняе ратацыю ключоў для хастоў за балансавальнікамі нагрузкі.
- У sshd дададзены налады PerSourceMaxStartups і PerSourceNetBlockSize для абмежавання інтэнсіўнасці запуску апрацоўшчыкаў у прывязцы да адрасу кліента. Паказаныя параметры дазваляюць больш тонка кіраваць абмежаваннем на запуск працэсаў, у параўнанні з агульнай наладай MaxStartups.
- У ssh і sshd дададзена новая налада LogVerbose, якая дазваляе прымусова падняць узровень скіданай у лог адладкавай інфармацыі, з магчымасцю фільтрацыі па шаблонах, функцый і файлам.
- У ssh пры прыняцці новага хастовага ключа забяспечаны паказ усіх імёнаў хастоў і IP-адрасоў, асацыіраваных з ключом.
- У ssh дазволена ўказанне опцыі UserKnownHostsFile=none для адключэння выкарыстання файла known_hosts пры ідэнтыфікацыі хаставых ключоў.
- У ssh_config для ssh дададзена налада KnownHostsCommand, якая дазваляе атрымаць дадзеныя known_hosts з высновы паказанай каманды.
- У ssh_config для ssh дададзена опцыя PermitRemoteOpen, якая дазваляе абмежаваць кропку прызначэння пры выкарыстанні опцыі RemoteForward з SOCKS.
- У ssh для ключоў FIDO забяспечаны паўторны запыт PIN у выпадку збою аперацыі з лічбавым подпісам з-за некарэктнага PIN і адсутнасці запыту PIN у карыстача (напрыклад, калі не атрымалася атрымаць карэктныя біяметрычныя дадзеныя і прылада адкацілася на ручны ўвод PIN-а).
- У sshd у заснаваны на seccomp-bpf механізм ізаляцыі працэсу на платформе Linux дададзеная падтрымка дадатковых сістэмных выклікаў.
- Абноўлена ўтыліта contrib/ssh-copy-id.
Крыніца: opennet.ru