Paglabas ng OpenSSH 8.8 na may hindi pagpapagana ng suporta para sa rsa-sha digital signatures

Ang paglabas ng OpenSSH 8.8 ay nai-publish, isang bukas na pagpapatupad ng isang kliyente at server para sa pagtatrabaho gamit ang SSH 2.0 at SFTP protocol. Ang release ay kapansin-pansin para sa hindi pagpapagana bilang default ang kakayahang gumamit ng mga digital na lagda batay sa mga RSA key na may SHA-1 hash (“ssh-rsa”).

Ang pagtigil ng suporta para sa mga lagda ng "ssh-rsa" ay dahil sa tumaas na kahusayan ng mga pag-atake ng banggaan na may ibinigay na prefix (ang halaga ng pagpili ng isang banggaan ay tinatantya sa humigit-kumulang $50). 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”. Ang suporta para sa mga lagda ng RSA na may SHA-256 at SHA-512 na mga hash (rsa-sha2-256/512), na suportado mula noong OpenSSH 7.2, ay nananatiling hindi nagbabago.

Sa karamihan ng mga kaso, ang paghinto ng suporta para sa "ssh-rsa" ay hindi mangangailangan ng anumang mga manu-manong pagkilos mula sa mga user, dahil dati nang pinagana ng OpenSSH ang setting ng UpdateHostKeys bilang default, na awtomatikong naglilipat ng mga kliyente sa mas maaasahang mga algorithm. Para sa paglipat, ang extension ng protocol na "[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. Kung sakaling kumonekta sa mga host na may napakatandang bersyon ng OpenSSH sa panig ng kliyente, maaari mong piliing ibalik ang kakayahang gumamit ng "ssh-rsa" na mga lagda sa pamamagitan ng pagdaragdag sa ~/.ssh/config: Host old_hostname HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms + ssh-rsa

Niresolba din ng bagong bersyon ang isang isyu sa seguridad na dulot ng sshd, simula sa OpenSSH 6.2, na hindi maayos na nasimulan ang pangkat ng user kapag nagpapatupad ng mga utos na tinukoy sa mga direktiba ng AuthorizedKeysCommand at AuthorizedPrincipalsCommand. Ang mga direktiba na ito ay dapat na payagan ang mga utos na patakbuhin sa ilalim ng ibang user, ngunit sa katunayan ay minana nila ang listahan ng mga pangkat na ginamit kapag nagpapatakbo ng sshd. Posible, ang pag-uugaling ito, sa pagkakaroon ng ilang partikular na setting ng system, ay nagpapahintulot sa inilunsad na handler na makakuha ng karagdagang mga pribilehiyo sa system.

Kasama rin sa bagong tala sa paglabas ang babala na ang scp ay magiging default sa SFTP sa halip na sa legacy na SCP/RCP protocol. Gumagamit ang SFTP ng mas mahuhulaan na paraan ng pangangasiwa ng pangalan at hindi gumagamit ng pagpoproseso ng shell ng mga pattern ng glob sa mga pangalan ng file sa panig ng kabilang host, na lumilikha ng mga problema sa seguridad. Sa partikular, kapag gumagamit ng SCP at RCP, nagpapasya ang server kung aling mga file at direktoryo ang ipapadala sa kliyente, at sinusuri lamang ng kliyente ang kawastuhan ng mga ibinalik na pangalan ng bagay, na, sa kawalan ng wastong pagsusuri sa panig ng kliyente, ay nagbibigay-daan sa server upang ilipat ang iba pang mga pangalan ng file na naiiba sa mga hiniling. Ang SFTP protocol ay walang mga problemang ito, ngunit hindi sinusuportahan ang pagpapalawak ng mga espesyal na landas gaya ng “~/”. Upang matugunan ang pagkakaibang ito, ang nakaraang release ng OpenSSH ay nagpakilala ng bagong SFTP protocol extension sa ~/ at ~user/ na mga landas sa pagpapatupad ng SFTP server.

Pinagmulan: opennet.ru