Пасля чатырох месяцаў распрацоўкі рэліз , адкрытай рэалізацыі кліента і сервера для працы па пратаколах SSH 2.0 і SFTP.
Ключавым паляпшэннем у выпуску OpenSSH 8.2 стала магчымасць выкарыстання двухфактарнай аўтэнтыфікацыі пры дапамозе прылад, якія падтрымліваюць пратакол. , які развіваецца альянсам . U2F дазваляе ствараць недарагія апаратныя токены для пацверджання фізічнай прысутнасці карыстальніка, узаемадзеянне з якімі вырабляецца праз USB, Bluetooth ці NFC. Падобныя прылады прасоваюцца ў якасці сродку для двухфактарнай аўтэнтыфікацыі на сайтах, ужо падтрымліваюцца асноўнымі браўзэрамі і выпускаюцца рознымі вытворцамі, у тым ліку Yubico, Feitian, Thetis і Kensington.
Для ўзаемадзеяння з прыладамі, якія пацвярджаюць прысутнасць карыстальніка, у OpenSSH дададзены новыя тыпы ключоў "ecdsa-sk" і "ed25519-sk", у якіх выкарыстоўваюцца алгарытмы лічбавага подпісу ECDSA і Ed25519, у спалучэнні з хэшам SHA-256. Працэдуры ўзаемадзеяння з токенамі вынесены ў прамежкавую бібліятэку, якая загружаецца па аналогіі з бібліятэкай для падтрымкі PKCS#11 і з'яўляецца абвязкай над бібліятэкай. , якая прадстаўляе сродкі для камунікацыі з токена па-над USB (падтрымліваецца пратаколы FIDO U2F/CTAP 1 і FIDO 2.0/CTAP 2). Падрыхтаваная распрацоўшчыкамі OpenSSH прамежкавая бібліятэка libsk-libfido2 у асноўны склад libfido2, як і для 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 зараз магчымая ўстаноўка рэжыму прыярытэтызацыі трафіку. (Lower-Effort Per-Hop Behavior);
- У ssh пры ўсталёўцы значэння "AddKeysToAgent=yes", калі ключ не ўтрымоўвае палі з каментаром, ён будзе дададзены ў ssh-agent c указаннем у якасці каментара шляху да ключа. У
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