Paglabas ng OpenSSH 8.7

Pagkatapos ng apat na buwan ng pag-unlad, ang paglabas ng OpenSSH 8.7, isang bukas na pagpapatupad ng isang kliyente at server para sa pagtatrabaho sa mga protocol ng SSH 2.0 at SFTP, ay ipinakita.

Pangunahing pagbabago:

• Isang eksperimental na data transfer mode ang idinagdag sa scp gamit ang SFTP protocol sa halip na ang tradisyonal na SCP/RCP protocol. Gumagamit ang SFTP ng mas mahuhulaan na paraan ng pangangasiwa ng pangalan at hindi gumagamit ng shell processing ng mga pattern ng glob sa panig ng kabilang host, na lumilikha ng mga problema sa seguridad. Upang paganahin ang SFTP sa scp, ang "-s" na flag ay iminungkahi, ngunit sa hinaharap ay pinlano itong lumipat sa protocol na ito bilang default.
• Ang sftp-server ay nagpapatupad ng mga extension sa SFTP protocol upang palawakin ang ~/ at ~user/ na mga landas, na kinakailangan para sa scp.
• Binago ng scp utility ang pag-uugali kapag kumukopya ng mga file sa pagitan ng dalawang malayuang host (halimbawa, “scp host-a:/path host-b:”), na ginagawa na ngayon bilang default sa pamamagitan ng intermediate local host, tulad ng kapag tinukoy ang “ -3” bandila. Ang diskarte na ito ay nagbibigay-daan sa iyo upang maiwasan ang pagpasa ng hindi kinakailangang mga kredensyal sa unang host at triple interpretasyon ng mga pangalan ng file sa shell (sa pinagmulan, patutunguhan at lokal na bahagi ng system), at kapag gumagamit ng SFTP, pinapayagan ka nitong gamitin ang lahat ng mga pamamaraan ng pagpapatunay kapag nag-access sa remote host, at hindi lamang mga non-interactive na pamamaraan . Ang opsyong "-R" ay naidagdag upang maibalik ang dating gawi.
• Idinagdag ang setting ng ForkAfterAuthentication sa ssh na tumutugma sa flag na "-f".
• Idinagdag ang setting ng StdinNull sa ssh, na tumutugma sa flag na "-n".
• Ang isang setting ng SessionType ay naidagdag sa ssh, kung saan maaari kang magtakda ng mga mode na tumutugma sa mga flag na “-N” (walang session) at “-s” (subsystem).
• Binibigyang-daan ka ng ssh-keygen na tumukoy ng agwat ng validity ng key sa mga key file.
• Idinagdag ang flag na "-Oprint-pubkey" sa ssh-keygen upang i-print ang buong pampublikong key bilang bahagi ng sshsig signature.
• Sa ssh at sshd, parehong client at server ay inilipat na gumamit ng mas mahigpit na configuration file parser na gumagamit ng shell-like na mga panuntunan para sa paghawak ng mga quote, space, at escape character. Hindi rin binabalewala ng bagong parser ang mga naunang ginawang pagpapalagay, gaya ng pag-alis ng mga argumento sa mga opsyon (halimbawa, ang direktiba ng DenyUsers ay hindi na maaaring iwanang walang laman), hindi nakasarang mga panipi, at pagtukoy ng maramihang = character.
• Kapag gumagamit ng mga tala ng SSHFP DNS kapag nagbe-verify ng mga susi, sinusuri na ngayon ng ssh ang lahat ng tumutugmang tala, hindi lamang ang mga naglalaman ng isang partikular na uri ng digital na lagda.
• Sa ssh-keygen, kapag bumubuo ng FIDO key na may opsyong -Ochallenge, ang built-in na layer ay ginagamit na ngayon para sa pag-hash, sa halip na libfido2, na nagbibigay-daan sa paggamit ng mga sequence ng hamon na mas malaki o mas maliit sa 32 bytes.
• Sa sshd, kapag nagpoproseso ng environment="..." na mga direktiba sa mga authorized_keys na file, tinatanggap na ngayon ang unang tugma at may limitasyon na 1024 na mga pangalan ng variable ng kapaligiran.

Nagbabala rin ang mga developer ng OpenSSH tungkol sa pagkabulok ng mga algorithm gamit ang SHA-1 na mga hash dahil sa tumaas na kahusayan ng mga pag-atake ng banggaan na may ibinigay na prefix (ang halaga ng pagpili ng banggaan ay tinatantya sa humigit-kumulang 50 libong dolyar). Sa susunod na release, plano naming 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 malawakang ginagamit 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”. Kasabay nito, ang hindi pagpapagana ng "ssh-rsa" na mga digital na lagda bilang default ay hindi nangangahulugan ng kumpletong pag-abandona sa paggamit ng mga RSA key, dahil bilang karagdagan sa SHA-1, pinapayagan ng SSH protocol ang paggamit ng iba pang mga algorithm ng pagkalkula ng hash. Sa partikular, bilang karagdagan sa "ssh-rsa", mananatiling posible na gamitin ang mga bundle na "rsa-sha2-256" (RSA/SHA256) at "rsa-sha2-512" (RSA/SHA512).

Para maayos ang paglipat sa mga bagong algorithm, dati nang pinagana ng OpenSSH ang setting ng UpdateHostKeys bilang default, na nagpapahintulot sa mga kliyente na awtomatikong lumipat sa mas maaasahang mga algorithm. Gamit ang setting na ito, pinagana ang isang espesyal na extension ng protocol "[protektado ng email]", na nagpapahintulot sa server, pagkatapos ng pagpapatunay, na ipaalam sa kliyente ang tungkol sa lahat ng magagamit na mga key ng host. Maaaring ipakita ng kliyente ang mga key na ito sa ~/.ssh/known_hosts file nito, na nagpapahintulot sa mga host key na ma-update at ginagawang mas madali ang pagbabago ng mga key sa server.

Ang paggamit ng UpdateHostKeys ay nililimitahan ng ilang mga caveat na maaaring alisin sa hinaharap: ang susi ay dapat na i-reference sa UserKnownHostsFile at hindi ginagamit sa GlobalKnownHostsFile; ang susi ay dapat naroroon sa ilalim lamang ng isang pangalan; hindi dapat gumamit ng host key certificate; sa known_hosts masks sa pamamagitan ng host name ay hindi dapat gamitin; ang VerifyHostKeyDNS na setting ay dapat na hindi pinagana; Dapat na aktibo ang parameter ng UserKnownHostsFile.

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).

Pinagmulan: opennet.ru