ProHoster > Blog > balita sa internet > Paglabas ng OpenSSH 8.4

Paglabas ng OpenSSH 8.4

Pagkatapos ng apat na buwan ng pag-unlad ipinakita paglabas ng OpenSSH 8.4, isang bukas na client at pagpapatupad ng server para sa pagtatrabaho gamit ang SSH 2.0 at SFTP protocol.

Pangunahing pagbabago:

  • Mga pagbabago sa seguridad:
    • Sa ssh-agent, kapag gumagamit ng FIDO keys na hindi ginawa para sa SSH authentication (ang key ID ay hindi nagsisimula sa string na "ssh:"), sinusuri nito ngayon na ang mensahe ay lalagdaan gamit ang mga pamamaraan na ginamit sa SSH protocol. Hindi papayagan ng pagbabago ang ssh-agent na ma-redirect sa mga malayuang host na mayroong FIDO key upang harangan ang kakayahang gamitin ang mga key na ito para makabuo ng mga lagda para sa mga kahilingan sa pagpapatotoo sa web (ang reverse case, kapag ang isang browser ay maaaring pumirma ng isang kahilingan sa SSH, ay hindi kasama sa simula. dahil sa paggamit ng prefix na β€œssh:” sa key identifier).
    • Kasama sa pagbuo ng resident key ng ssh-keygen ang suporta para sa add-on ng credProtect na inilarawan sa detalye ng FIDO 2.1, na nagbibigay ng karagdagang proteksyon para sa mga key sa pamamagitan ng pag-aatas ng PIN bago magsagawa ng anumang operasyon na maaaring magresulta sa pagkuha ng resident key mula sa token.
  • Posibleng masira ang mga pagbabago sa compatibility:
    • Upang suportahan ang FIDO/U2F, inirerekomendang gamitin ang libfido2 library kahit man lang bersyon 1.5.0. Ang kakayahang gumamit ng mas lumang mga edisyon ay bahagyang ipinatupad, ngunit sa kasong ito, ang mga function tulad ng mga resident key, kahilingan sa PIN, at pagkonekta ng maraming token ay hindi magiging available.
    • Sa ssh-keygen, ang data ng authenticator na kinakailangan para sa pag-verify ng pagkumpirma ng mga digital na lagda ay idinagdag sa format ng impormasyon sa pagkumpirma, na opsyonal na nai-save kapag bumubuo ng FIDO key.
    • Ang API na ginamit kapag nakipag-ugnayan ang OpenSSH sa layer para sa pag-access ng mga token ng FIDO ay nabago.
    • Kapag gumagawa ng portable na bersyon ng OpenSSH, kailangan na ngayon ng automake na buuin ang script ng pag-configure at mga kasamang build file (kung bubuo mula sa isang naka-publish na code na tar file, hindi kinakailangan ang regenerating configure).
  • Nagdagdag ng suporta para sa mga FIDO key na nangangailangan ng pag-verify ng PIN sa ssh at ssh-keygen. Upang makabuo ng mga susi gamit ang PIN, idinagdag sa ssh-keygen ang opsyong "kinakailangan ng pag-verify". Kung ginamit ang mga naturang key, bago isagawa ang pagpapatakbo ng paggawa ng lagda, ipo-prompt ang user na kumpirmahin ang kanilang mga aksyon sa pamamagitan ng paglalagay ng PIN code.
  • Sa sshd, ang opsyon na "kinakailangan ng pag-verify" ay ipinatupad sa setting ng authorized_keys, na nangangailangan ng paggamit ng mga kakayahan upang i-verify ang presensya ng user sa panahon ng mga operasyon gamit ang token. Ang pamantayan ng FIDO ay nagbibigay ng ilang mga opsyon para sa naturang pag-verify, ngunit sa kasalukuyan ang OpenSSH ay sumusuporta lamang sa PIN-based na pag-verify.
  • Ang sshd at ssh-keygen ay nagdagdag ng suporta para sa pag-verify ng mga digital na lagda na sumusunod sa pamantayan ng FIDO Webauthn, na nagpapahintulot sa mga FIDO key na magamit sa mga web browser.
  • Sa ssh sa mga setting ng CertificateFile,
    ControlPath, IdentityAgent, IdentityFile, LocalForward at
    Pinapayagan ng RemoteForward ang pagpapalit ng mga halaga mula sa mga variable ng kapaligiran na tinukoy sa format na "${ENV}".

  • Ang ssh at ssh-agent ay nagdagdag ng suporta para sa variable ng kapaligiran na $SSH_ASKPASS_REQUIRE, na maaaring magamit upang paganahin o huwag paganahin ang ssh-askpass na tawag.
  • Sa ssh sa ssh_config sa AddKeysToAgent directive, naidagdag ang kakayahang limitahan ang validity period ng isang key. Matapos mag-expire ang tinukoy na limitasyon, ang mga susi ay awtomatikong tatanggalin mula sa ssh-agent.
  • Sa scp at sftp, gamit ang flag na "-A", maaari mo na ngayong tahasang payagan ang pag-redirect sa scp at sftp gamit ang ssh-agent (naka-disable ang redirection bilang default).
  • Nagdagdag ng suporta para sa '%k' na pagpapalit sa mga setting ng ssh, na tumutukoy sa pangalan ng host key. Maaaring gamitin ang feature na ito para ipamahagi ang mga key sa magkakahiwalay na file (halimbawa, β€œUserKnownHostsFile ~/.ssh/known_hosts.d/%k”).
  • Payagan ang paggamit ng "ssh-add -d -" na operasyon upang basahin ang mga key mula sa stdin na tatanggalin.
  • Sa sshd, ang simula at pagtatapos ng proseso ng pruning ng koneksyon ay makikita sa log, na kinokontrol gamit ang MaxStartups parameter.

Naalala rin ng mga developer ng OpenSSH ang paparating na pag-decommissioning ng mga algorithm gamit ang SHA-1 na mga hash dahil sa promosyon 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”).

Para maayos ang paglipat sa mga bagong algorithm sa OpenSSH, ang susunod na release ay magbibigay-daan sa setting ng UpdateHostKeys 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).

Pinagmulan: opennet.ru

Magdagdag ng komento