Lëshimi i OpenSSH 8.5

Pas pesë muajsh zhvillimi, paraqitet lëshimi i OpenSSH 8.5, një zbatim i hapur i një klienti dhe serveri për të punuar mbi protokollet SSH 2.0 dhe SFTP.

Zhvilluesit e OpenSSH na kujtuan çmontimin e ardhshëm të algoritmeve që përdorin hash SHA-1 për shkak të rritjes së efikasitetit të sulmeve të përplasjeve me një prefiks të caktuar (kostoja e zgjedhjes së një përplasjeje vlerësohet në rreth 50 mijë dollarë). Në një nga publikimet e ardhshme, ata planifikojnë të çaktivizojnë si parazgjedhje aftësinë për të përdorur algoritmin e nënshkrimit dixhital të çelësit publik "ssh-rsa", i cili përmendet në origjinalin RFC për protokollin SSH dhe mbetet i përhapur në praktikë.

Për të testuar përdorimin e ssh-rsa në sistemet tuaja, mund të provoni të lidheni nëpërmjet ssh me opsionin “-oHostKeyAlgorithms=-ssh-rsa”. Në të njëjtën kohë, çaktivizimi i nënshkrimeve dixhitale "ssh-rsa" si parazgjedhje nuk do të thotë një braktisje e plotë e përdorimit të çelësave RSA, pasi përveç SHA-1, protokolli SSH lejon përdorimin e algoritmeve të tjera të llogaritjes hash. Në veçanti, përveç "ssh-rsa", do të mbetet i mundur përdorimi i paketave "rsa-sha2-256" (RSA/SHA256) dhe "rsa-sha2-512" (RSA/SHA512).

Për të qetësuar kalimin në algoritme të reja, OpenSSH 8.5 ka të aktivizuar si parazgjedhje cilësimin UpdateHostKeys, i cili lejon klientët të kalojnë automatikisht në algoritme më të besueshme. Duke përdorur këtë cilësim, aktivizohet një shtesë e veçantë e protokollit "[email mbrojtur]", duke lejuar serverin, pas vërtetimit, të informojë klientin për të gjithë çelësat e disponueshëm të hostit. Klienti mund t'i pasqyrojë këta çelësa në skedarin e tij ~/.ssh/known_hosts, i cili lejon që çelësat e hostit të përditësohen dhe e bën më të lehtë ndryshimin e çelësave në server.

Përdorimi i UpdateHostKeys është i kufizuar nga disa paralajmërime që mund të hiqen në të ardhmen: çelësi duhet të referohet në UserKnownHostsFile dhe të mos përdoret në GlobalKnownHostsFile; çelësi duhet të jetë i pranishëm vetëm me një emër; nuk duhet të përdoret një certifikatë kryesore kryesore; në Known_hosts maskat sipas emrit të hostit nuk duhet të përdoren; cilësimi VerifyHostKeyDNS duhet të jetë i çaktivizuar; Parametri UserKnownHostsFile duhet të jetë aktiv.

Algoritmet e rekomanduara për migrim përfshijnë rsa-sha2-256/512 bazuar në RFC8332 RSA SHA-2 (mbështetur që nga OpenSSH 7.2 dhe përdoret si parazgjedhje), ssh-ed25519 (mbështetur që nga OpenSSH 6.5) dhe ecdsa-sha2-nistp256/384 bazuar në RFC521 ECDSA (mbështetur që nga OpenSSH 5656).

Ndryshime të tjera:

  • Ndryshimet e sigurisë:
    • Një cenueshmëri e shkaktuar nga ri-lirimi i një zone memorie tashmë të çliruar (pa dyfish) është rregulluar në ssh-agent. Çështja ka qenë e pranishme që nga lëshimi i OpenSSH 8.2 dhe potencialisht mund të shfrytëzohet nëse një sulmues ka akses në prizën ssh-agent në sistemin lokal. Ajo që e bën më të vështirë shfrytëzimin është se vetëm root dhe përdoruesi origjinal kanë akses në socket. Skenari më i mundshëm i sulmit është që agjenti të ridrejtohet në një llogari që kontrollohet nga sulmuesi, ose në një host ku sulmuesi ka qasje rrënjësore.
    • sshd ka shtuar mbrojtje kundër kalimit të parametrave shumë të mëdhenj me emrin e përdoruesit në nënsistemin PAM, i cili ju lejon të bllokoni dobësitë në modulet e sistemit PAM (Pluggable Authentication Module). Për shembull, ndryshimi parandalon që sshd të përdoret si një vektor për të shfrytëzuar një cenueshmëri rrënjësore të zbuluar së fundmi në Solaris (CVE-2020-14871).
  • Ndryshimet e mundshme të prishjes së përputhshmërisë:
    • В ssh и sshd переработан экспериментальный метод обмена ключами, стойкий к подбору на квантовом компьютере. Квантовые компьютеры кардинально быстрее решают задачу разложения натурального числа на простые множители, которая лежит в основе современных асимметричных алгоритмов шифрования и эффективно не решаема на классических процессорах. Используемый метод основан на алгоритме NTRU Prime, разработанном для постквантумных криптосистем, и методе обмена ключами на базе эллиптических кривых X25519. Вместо [email mbrojtur] метод теперь идентифицируется как [email mbrojtur] (algoritmi sntrup4591761 është zëvendësuar nga sntrup761).
    • Në ssh dhe sshd, radha në të cilën shpallen algoritmet e nënshkrimit dixhital të mbështetur është ndryshuar. ED25519 tani ofrohet i pari në vend të ECDSA.
    • Në ssh dhe sshd, vendosja e parametrave të cilësisë së shërbimit TOS/DSCP për seancat interaktive bëhet tani përpara se të vendoset një lidhje TCP.
    • Mbështetja e shifrave është ndërprerë në ssh dhe sshd [email mbrojtur], i cili është identik me aes256-cbc dhe është përdorur përpara miratimit të RFC-4253.
    • Si parazgjedhje, parametri CheckHostIP është i çaktivizuar, përfitimi i të cilit është i papërfillshëm, por përdorimi i tij komplikon ndjeshëm rrotullimin e çelësave për hostet pas balancuesve të ngarkesës.
  • Cilësimet e PerSourceMaxStartups dhe PerSourceNetBlockSize janë shtuar në sshd për të kufizuar intensitetin e lëshimit të mbajtësve bazuar në adresën e klientit. Këta parametra ju lejojnë të kontrolloni më hollësisht kufirin në nisjen e procesit, krahasuar me cilësimin e përgjithshëm të MaxStartups.
  • Një cilësim i ri LogVerbose është shtuar në ssh dhe sshd, i cili ju lejon të rritni me forcë nivelin e informacionit të korrigjimit të hedhur në regjistër, me aftësinë për të filtruar sipas shablloneve, funksioneve dhe skedarëve.
  • Në ssh, kur pranohet një çelës i ri pritës, shfaqen të gjithë emrat e hosteve dhe adresat IP të lidhura me çelësin.
  • ssh lejon që opsioni UserKnownHostsFile=none të çaktivizojë përdorimin e skedarit Known_hosts kur identifikon çelësat pritës.
  • Një cilësim KnownHostsCommand është shtuar në ssh_config për ssh, duke ju lejuar të merrni të dhëna të njohura_hosts nga dalja e komandës së specifikuar.
  • Shtoi një opsion PermitRemoteOpen te ssh_config për ssh për t'ju lejuar të kufizoni destinacionin kur përdorni opsionin RemoteForward me SOCKS.
  • Në ssh për çelësat FIDO, një kërkesë e përsëritur PIN ofrohet në rast të dështimit të funksionimit të nënshkrimit dixhital për shkak të një kodi PIN të pasaktë dhe përdoruesit nuk i kërkohet një PIN (për shembull, kur nuk mund të merren të dhënat e sakta biometrike dhe pajisja u kthye në futjen manuale të PIN-it).
  • sshd shton mbështetje për thirrjet shtesë të sistemit në mekanizmin e izolimit të procesit të bazuar në seccomp-bpf në Linux.
  • Programi kontribut/ssh-copy-id është përditësuar.

Burimi: opennet.ru

Shto një koment