Pas katër muajsh zhvillimi, u prezantua në qarkullim OpenSSH 8.7, një implementim i hapur i një klienti dhe serveri për të punuar mbi protokollet SSH 2.0 dhe SFTP.
Ndryshimet kryesore:
- Një mënyrë eksperimentale e transferimit të të dhënave është shtuar në scp duke përdorur protokollin SFTP në vend të protokollit tradicional SCP/RCP. SFTP përdor metoda më të parashikueshme të trajtimit të emrit dhe nuk përdor përpunimin e guaskës së modeleve glob në anën e hostit tjetër, gjë që krijon probleme sigurie. Për të aktivizuar SFTP në scp, është propozuar flamuri “-s”, por në të ardhmen është planifikuar kalimi në këtë protokoll si parazgjedhje.
- sftp-server implementon shtesa në protokollin SFTP për të zgjeruar shtigjet ~/ dhe ~user/, e cila është e nevojshme për scp.
- Shërbimi scp ka ndryshuar sjelljen kur kopjon skedarë midis dy hosteve të largët (për shembull, "scp host-a:/path host-b:"), i cili tani bëhet si parazgjedhje përmes një hosti lokal të ndërmjetëm, si kur specifikohet " -3” flamur. Kjo qasje ju lejon të shmangni kalimin e kredencialeve të panevojshme në hostin e parë dhe interpretimin e trefishtë të emrave të skedarëve në guaskë (në burimin, destinacionin dhe anën e sistemit lokal), dhe kur përdorni SFTP, ju lejon të përdorni të gjitha metodat e vërtetimit kur hyni në distancë hostet, dhe jo vetëm metodat jo-interaktive . Opsioni "-R" është shtuar për të rivendosur sjelljen e vjetër.
- U shtua cilësimi i ForkAfterAuthentication në ssh që korrespondon me flamurin "-f".
- U shtua cilësimi StdinNull në ssh, që korrespondon me flamurin "-n".
- Një cilësim SessionType është shtuar në ssh, përmes të cilit mund të vendosni mënyra që korrespondojnë me flamujt "-N" (pa sesion) dhe "-s" (nënsistem).
- ssh-keygen ju lejon të specifikoni një interval të vlefshmërisë së çelësit në skedarët kyç.
- U shtua flamuri "-Oprint-pubkey" në ssh-keygen për të printuar çelësin e plotë publik si pjesë e nënshkrimit sshsig.
- Në ssh dhe sshd, klienti dhe serveri janë zhvendosur për të përdorur një analizues më kufizues të skedarëve të konfigurimit që përdor rregulla të ngjashme me guaskën për trajtimin e kuotave, hapësirave dhe karaktereve të arratisjes. Analisti i ri gjithashtu nuk injoron supozimet e bëra më parë, të tilla si heqja e argumenteve në opsione (për shembull, direktiva e DenyUsers nuk mund të lihet më bosh), thonjëzat e pambyllura dhe specifikimi i shumëfishtë = karaktereve.
- Kur përdorni të dhënat SSHFP DNS kur verifikoni çelësat, ssh tani kontrollon të gjitha të dhënat që përputhen, jo vetëm ato që përmbajnë një lloj specifik të nënshkrimit dixhital.
- Në ssh-keygen, kur gjenerohet një çelës FIDO me opsionin -Ochallenge, shtresa e integruar tani përdoret për hash, në vend të libfido2, e cila lejon përdorimin e sekuencave sfiduese më të mëdha ose më të vogla se 32 bajt.
- Në sshd, kur përpunohen direktivat e mjedisit="..." në skedarët e autorizuar_çelësat, përputhja e parë tani pranohet dhe ka një kufi prej 1024 emrash të ndryshoreve mjedisore.
Zhvilluesit e OpenSSH paralajmëruan gjithashtu për dekompozimin e algoritmeve që përdorin hash SHA-1 për shkak të rritjes së efikasitetit të sulmeve të përplasjes me një prefiks të caktuar (kostoja e zgjedhjes së një përplasjeje vlerësohet në afërsisht 50 mijë dollarë). Në versionin e ardhshëm, ne planifikojmë të çaktivizojmë si parazgjedhje aftësinë për të përdorur algoritmin e nënshkrimit dixhital të çelësit publik "ssh-rsa", i cili u përmend në origjinalin RFC për protokollin SSH dhe mbetet gjerësisht i përdorur 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 më parë kishte 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).
Burimi: opennet.ru