Sawise limang sasi pembangunan, release saka OpenSSH 8.5, implementasine mbukak saka klien lan server kanggo nggarap protokol SSH 2.0 lan SFTP.
Pangembang OpenSSH ngelingake kita babagan decommissioning algoritma sing bakal teka nggunakake hash SHA-1 amarga tambah efisiensi serangan tabrakan kanthi prefiks sing diwenehake (biaya kanggo milih tabrakan kira-kira $ 50 ewu). Ing salah siji saka rilis mbesuk, padha rencana kanggo mateni kanthi standar kemampuan kanggo nggunakake "ssh-rsa" algoritma teken digital tombol umum, kang kasebut ing RFC asli kanggo protokol SSH lan tetep nyebar ing laku.
Kanggo nguji panggunaan ssh-rsa ing sistem sampeyan, sampeyan bisa nyoba nyambungake liwat ssh nganggo opsi "-oHostKeyAlgorithm=-ssh-rsa". Ing wektu sing padha, mateni tandha digital "ssh-rsa" kanthi standar ora ateges nglirwakake panggunaan tombol RSA, amarga saliyane SHA-1, protokol SSH ngidini nggunakake algoritma pitungan hash liyane. Utamane, saliyane "ssh-rsa", bakal tetep bisa nggunakake bundel "rsa-sha2-256" (RSA / SHA256) lan "rsa-sha2-512" (RSA / SHA512).
Kanggo nglancarake transisi menyang algoritma anyar, OpenSSH 8.5 nduweni setelan UpdateHostKeys sing diaktifake kanthi standar, sing ngidini klien kanthi otomatis ngalih menyang algoritma sing luwih dipercaya. Nggunakake setelan iki, ekstensi protokol khusus diaktifake "[email dilindhungi]", ngidini server, sawise otentikasi, ngandhani klien babagan kabeh kunci host sing kasedhiya. Klien bisa nggambarake kunci kasebut ing file ~/.ssh/known_hosts, sing ngidini kunci host dianyari lan luwih gampang ngganti tombol ing server.
Panggunaan UpdateHostKeys diwatesi dening sawetara caveat sing bisa dibusak ing mangsa ngarep: kunci kasebut kudu dirujuk ing UserKnownHostsFile lan ora digunakake ing GlobalKnownHostsFile; tombol kudu ana mung siji jeneng; sertifikat kunci inang ora kudu digunakake; ing topeng known_hosts kanthi jeneng host ora kudu digunakake; setelan VerifyHostKeyDNS kudu dipateni; Parameter UserKnownHostsFile kudu aktif.
Algoritma sing disaranake kanggo migrasi kalebu rsa-sha2-256/512 adhedhasar RFC8332 RSA SHA-2 (didhukung wiwit OpenSSH 7.2 lan digunakake kanthi standar), ssh-ed25519 (didhukung wiwit OpenSSH 6.5) lan adhedhasar ecdsa-sha2-nistp256/384/521. ing RFC5656 ECDSA (didhukung wiwit OpenSSH 5.7).
Owah-owahan liyane:
- Owah-owahan keamanan:
- Kerentanan sing disebabake dening mbebasake maneh area memori sing wis dibebasake (bebas pindho) wis diatasi ing ssh-agent. Masalah kasebut wis ana wiwit diluncurake OpenSSH 8.2 lan bisa dimanfaatake yen panyerang duwe akses menyang soket ssh-agen ing sistem lokal. Sing nggawe eksploitasi luwih angel yaiku mung ROOT lan pangguna asli sing duwe akses menyang soket. Skenario serangan sing paling mungkin yaiku agen kasebut dialihake menyang akun sing dikontrol dening panyerang, utawa menyang host sing panyerang duwe akses root.
- sshd wis nambah pangayoman marang pass paramèter gedhe banget karo jeneng pangguna menyang subsistem PAM, sing ngijini sampeyan kanggo mblokir kerentanan ing modul sistem PAM (Pluggable Authentication Module). Contone, pangowahan kasebut nyegah sshd digunakake minangka vektor kanggo ngeksploitasi kerentanan root sing bubar ditemokake ing Solaris (CVE-2020-14871).
- Owah-owahan kompatibilitas sing bisa rusak:
- Ing ssh lan sshd, metode pertukaran kunci eksperimen wis didesain ulang sing tahan kanggo ngira ing komputer kuantum. Komputer kuantum kanthi radikal luwih cepet kanggo ngrampungake masalah ngurai angka alami dadi faktor prima, sing ndasari algoritma enkripsi asimetris modern lan ora bisa ditanggulangi kanthi efektif ing prosesor klasik. Cara sing digunakake adhedhasar algoritma NTRU Prime, sing dikembangake kanggo kriptosistem pasca-kuantum, lan metode pertukaran kunci kurva eliptik X25519. Tinimbang [email dilindhungi] cara saiki dikenali minangka [email dilindhungi] (algoritma sntrup4591761 wis diganti dening sntrup761).
- Ing ssh lan sshd, urutan sing didhukung algoritma tandha digital diumumake wis diganti. ED25519 saiki ditawakake luwih dhisik tinimbang ECDSA.
- Ing ssh lan sshd, nyetel parameter layanan TOS/DSCP kanggo sesi interaktif saiki wis rampung sadurunge nggawe sambungan TCP.
- Dhukungan cipher wis mandheg ing ssh lan sshd [email dilindhungi], sing identik karo aes256-cbc lan digunakake sadurunge RFC-4253 disetujoni.
- Kanthi gawan, paramèter CheckHostIP dipatèni, mupangat sing bisa diabaikan, nanging panggunaan kasebut rumit banget kanggo rotasi tombol kanggo host ing mburi penyeimbang beban.
- Setelan PerSourceMaxStartups lan PerSourceNetBlockSize wis ditambahake menyang sshd kanggo mbatesi intensitas penangan sing diluncurake adhedhasar alamat klien. Paramèter kasebut ngidini sampeyan ngontrol watesan ing proses peluncuran, dibandhingake karo setelan MaxStartups umum.
- Setelan LogVerbose anyar wis ditambahake menyang ssh lan sshd, sing ngidini sampeyan kanthi paksa ngunggahake tingkat informasi debugging sing dibuwang menyang log, kanthi kemampuan kanggo nyaring miturut cithakan, fungsi lan file.
- Ing ssh, nalika nampa kunci host anyar, kabeh jeneng host lan alamat IP sing digandhengake karo kunci ditampilake.
- ssh ngidini UserKnownHostsFile = ora ana pilihan kanggo mateni panggunaan file known_hosts nalika ngenali kunci host.
- Setelan KnownHostsCommand wis ditambahake menyang ssh_config kanggo ssh, ngidini sampeyan entuk data known_hosts saka output perintah kasebut.
- Nambahake opsi PermitRemoteOpen menyang ssh_config kanggo ssh supaya sampeyan bisa mbatesi tujuan nalika nggunakake pilihan RemoteForward karo SOCKS.
- Ing ssh kanggo tombol FIDO, panjalukan PIN bola-bali diwenehake yen ana kegagalan operasi tandha digital amarga PIN sing salah lan pangguna ora dijaluk PIN (contone, nalika data biometrik sing bener ora bisa dipikolehi lan piranti bali menyang entri PIN manual).
- sshd nambahake dhukungan kanggo panggilan sistem tambahan menyang mekanisme isolasi proses berbasis seccomp-bpf ing Linux.
- Utilitas contrib/ssh-copy-id wis dianyari.
Source: opennet.ru