Pagkatapos ng apat na buwan ng pag-unlad pakawalan , isang bukas na pagpapatupad ng kliyente at server para sa pagtatrabaho sa pamamagitan ng mga protocol ng SSH 2.0 at SFTP.
Ang isang pangunahing pagpapabuti sa paglabas ng OpenSSH 8.2 ay ang kakayahang gumamit ng dalawang-factor na pagpapatotoo sa mga device na sumusuporta sa protocol. , binuo ng alyansa Ang U2F ay nagbibigay-daan sa paglikha ng mga murang hardware na token upang i-verify ang pisikal na presensya ng isang user, na nakikipag-ugnayan sa kanila sa pamamagitan ng USB, Bluetooth, o NFC. Ang mga device na ito ay pino-promote bilang isang paraan ng two-factor authentication sa mga website, sinusuportahan na ng mga pangunahing browser, at ginawa ng iba't ibang manufacturer, kabilang ang Yubico, Feitian, Thetis, at Kensington.
Upang makipag-ugnayan sa mga device na nagkukumpirma sa presensya ng user, nagdagdag ang OpenSSH ng mga bagong uri ng key, "ecdsa-sk" at "ed25519-sk," na gumagamit ng ECDSA at Ed25519 digital signature algorithm kasama ng SHA-256 hash. Ang mga pamamaraan para sa pakikipag-ugnayan sa mga token ay inilipat sa isang intermediate na library, na na-load nang katulad sa PKCS#11 support library at nagsisilbing wrapper sa paligid ng library. , na nagbibigay ng paraan para sa pakikipag-ugnayan sa mga token gamit ang USB (FIDO U2F/CTAP 1 at FIDO 2.0/CTAP 2 protocol ay sinusuportahan). Ang libsk-libfido2 intermediate library, na inihanda ng mga developer ng OpenSSH, sa pangunahing komposisyon ng libfido2, pati na rin para sa OpenBSD.
Upang mag-authenticate at makabuo ng key, dapat mong tukuyin ang parameter na "SecurityKeyProvider" sa mga setting o itakda ang variable ng kapaligiran ng SSH_SK_PROVIDER, na tumutukoy sa path patungo sa external na library na libsk-libfido2.so (i-export ang SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). Maaaring itayo ang OpenSSH na may built-in na suporta para sa intermediary library (--with-security-key-builtin); sa kasong ito, dapat mong itakda ang parameter na "SecurityKeyProvider=internal".
Susunod, patakbuhin ang "ssh-keygen -t ecdsa-sk" o, kung nagawa at na-configure na ang mga key, kumonekta sa server gamit ang "ssh." Kapag nagpatakbo ka ng ssh-keygen, ang nabuong pares ng key ay mase-save sa "~/.ssh/id_ecdsa_sk" at maaaring gamitin tulad ng iba pang mga key.
Ang pampublikong key (id_ecdsa_sk.pub) ay dapat makopya sa authorized_keys file sa server. Bine-verify lang ng server ang digital signature, habang nangyayari ang pakikipag-ugnayan ng token sa client (hindi kailangang i-install ang libsk-libfido2 sa server, ngunit dapat suportahan ng server ang uri ng key na "ecdsa-sk"). Ang nabuong pribadong susi (id_ecdsa_sk) ay mahalagang tagapaglarawan ng pangunahing susi na bumubuo lamang ng tunay na susi kapag pinagsama sa lihim na pagkakasunud-sunod na nakaimbak sa U2F token. Kung makuha ng isang attacker ang id_ecdsa_sk key, kakailanganin din nila ng access sa hardware token para ma-authenticate, kung wala ang pribadong key na nakaimbak sa id_ecdsa_sk file ay walang silbi.
Higit pa rito, bilang default, ang lahat ng pangunahing operasyon (parehong henerasyon at pagpapatotoo) ay nangangailangan ng lokal na kumpirmasyon ng pisikal na presensya ng user, tulad ng pagpindot sa isang sensor sa token, na nagpapahirap sa pagsasagawa ng malayuang pag-atake sa mga system na may konektadong token. Bilang karagdagang layer ng seguridad, ang isang password para sa pag-access sa key file ay maaari ding itakda sa panahon ng ssh-keygen startup.
Inanunsyo din ng bagong bersyon ng OpenSSH ang paparating na paghinto ng paggamit ng mga algorithm gamit ang SHA-1 na mga hash dahil sa ang pagiging epektibo ng mga pag-atake ng banggaan na may isang naibigay na prefix (ang halaga ng pagpili ng isang banggaan ay tinatantya sa humigit-kumulang 45 libong dolyar). Sa isa sa mga paparating na release, plano nilang i-disable bilang default ang kakayahang gamitin ang public key digital signature algorithm na "ssh-rsa", na binanggit sa orihinal na RFC para sa SSH protocol at nananatiling laganap sa pagsasanay (upang subukan ang paggamit ng ssh-rsa sa iyong mga system, maaari mong subukang kumonekta sa pamamagitan ng ssh gamit ang opsyong “-oHostKeyAlgorithms=-ssh-rsa”).
Upang pabilisin ang paglipat sa mga bagong algorithm sa OpenSSH, sa susunod na release ang UpdateHostKeys setting ay paganahin bilang default, na awtomatikong maglilipat ng mga kliyente sa mas maaasahang mga algorithm. Kasama sa mga inirerekomendang algorithm para sa paglipat ang rsa-sha2-256/512 batay sa RFC8332 RSA SHA-2 (sinusuportahan mula noong OpenSSH 7.2 at ginamit bilang default), ssh-ed25519 (sinusuportahan mula noong OpenSSH 6.5) at ecdsa-sha2-nistp256/384/521 based sa RFC5656 ECDSA (sinusuportahan mula noong OpenSSH 5.7).
Sinusuportahan pa rin ng OpenSSH 8.2 ang pagkonekta gamit ang "ssh-rsa," ngunit ang algorithm na ito ay inalis mula sa listahan ng CASignatureAlgorithms, na tumutukoy sa mga algorithm na pinapayagan para sa digitally signing ng mga bagong certificate. Katulad nito, ang diffie-hellman-group14-sha1 algorithm ay inalis mula sa mga sinusuportahang default na key exchange algorithm. Napansin na ang paggamit ng SHA-1 sa mga certificate ay nagdadala ng karagdagang panganib, dahil ang isang umaatake ay may walang limitasyong oras upang makahanap ng banggaan para sa isang umiiral na certificate, habang ang mga pag-atake sa mga host key ay nalilimitahan ng timeout ng koneksyon (LoginGraceTime).
Kapag nagpapatakbo ng ssh-keygen, ang rsa-sha2-512 algorithm, na suportado mula noong OpenSSH 7.2, ay ginagamit na ngayon bilang default, na maaaring lumikha ng mga isyu sa compatibility kapag sinusubukang iproseso ang OpenSSH 8.2-signed na mga certificate sa mga system na nagpapatakbo ng mas lumang OpenSSH release (upang malutas ang isyung ito, maaari mong tahasang tukuyin ang "ssh-keygen -t" kapag bumubuo ng ssh-keygen -t ecdsa-sha2-nistp256/384/521 algorithm na suportado mula noong OpenSSH 5.7).
Iba pang mga pagbabago:
- Ang direktiba ng Isama ay naidagdag sa sshd_config, na nagpapahintulot sa mga nilalaman ng iba pang mga file na maisama sa kasalukuyang posisyon ng file ng pagsasaayos (maaaring gamitin ang mga glob mask kapag tinukoy ang pangalan ng file);
- Ang opsyon na "no-touch-required" ay idinagdag sa ssh-keygen, na hindi pinapagana ang pangangailangan para sa pisikal na kumpirmasyon ng pag-access sa token kapag bumubuo ng isang susi;
- Ang direktiba ng PubkeyAuthOptions ay idinagdag sa sshd_config, pinagsasama-sama ang iba't ibang mga opsyon na nauugnay sa pagpapatunay ng pampublikong key. Sa kasalukuyan, ang flag na "no-touch-required" lang ang sinusuportahan, na nagbibigay-daan sa paglaktaw sa physical presence check sa panahon ng token authentication. Katulad nito, ang opsyong "no-touch-required" ay naidagdag sa authorized_keys file.
- Ang opsyong "-O write-attestation=/path" ay idinagdag sa ssh-keygen, na nagpapahintulot sa karagdagang FIDO attestation certificate na maisulat kapag bumubuo ng mga key. Kasalukuyang hindi ginagamit ng OpenSSH ang mga certificate na ito, ngunit magagamit ang mga ito sa hinaharap upang i-verify na naka-store ang key sa pinagkakatiwalaang storage ng hardware.
- Sa ssh at sshd na mga setting, posible na ngayong itakda ang traffic prioritization mode sa pamamagitan ng IPQoS directive. (Lower-Effort Per-Hop Behavior);
- Sa ssh, kapag nagtatakda ng value na "AddKeysToAgent=yes", kung ang key ay hindi naglalaman ng field ng komento, idaragdag ito sa ssh-agent na may path sa key na tinukoy bilang komento.
Gumagamit na rin ngayon ang ssh-keygen at ssh-agent ng mga label ng PKCS#11 at ang X.509 na pangalan ng paksa bilang mga komento sa key sa halip na ang path ng library; - Nagdagdag ng kakayahang mag-export ng PEM para sa mga DSA at ECDSA key sa ssh-keygen;
- Nagdagdag ng bagong executable file na ssh-sk-helper, na ginamit upang ihiwalay ang access sa library sa mga token ng FIDO/U2F;
- Idinagdag ang "--with-zlib" build option sa ssh at sshd para sa pag-compile gamit ang zlib library support;
- Alinsunod sa RFC 4253, isang babala tungkol sa pag-block sa pag-access dahil sa paglampas sa limitasyon ng MaxStartups ay ipinapakita na ngayon sa banner ng koneksyon. Upang pasimplehin ang mga diagnostic, ipinapakita na ngayon ng sshd process header, na nakikita gamit ang ps utility, ang bilang ng kasalukuyang napatotohanan na mga koneksyon at ang katayuan ng limitasyon ng MaxStartups.
- Sa ssh at ssh-agent, kapag tumatawag sa isang programa upang ipakita ang isang imbitasyon sa screen, na tinukoy sa pamamagitan ng $SSH_ASKPASS, ang isang bandila na may uri ng imbitasyon ay ipapasa din ngayon: "kumpirmahin" - dialog ng kumpirmasyon (oo/hindi), "wala" - mensaheng nagbibigay-kaalaman, "blangko" - kahilingan ng password;
- Ang isang bagong digital signature operation na "find-principals" ay idinagdag sa ssh-keygen upang hanapin ang pinapayagang-signers file para sa user na nauugnay sa tinukoy na digital signature;
- Улучшена поддержка изоляции процесса sshd в Linux при помощи механизма seccomp: запрещены системные вызовы IPC, разрешены clock_gettime64(), clock_nanosleep_time64 и clock_nanosleep().
Pinagmulan: opennet.ru
