La eldono de OpenSSH 8.8 estis publikigita, malferma efektivigo de kliento kaj servilo por labori uzante la SSH 2.0 kaj SFTP-protokolojn. La eldono estas rimarkinda pro malfunkciigado defaŭlte la kapablo uzi ciferecajn subskribojn bazitajn sur RSA-ŝlosiloj kun SHA-1 hash ("ssh-rsa").
La ĉesigo de subteno por "ssh-rsa" subskriboj estas pro la pliigita efikeco de kolizio atakoj kun antaŭfiksita prefikso (la kosto de elekto de kolizio estas taksita je proksimume $ 50 mil). Por testi la uzon de ssh-rsa en viaj sistemoj, vi povas provi konekti per ssh kun la opcio "-oHostKeyAlgorithms=-ssh-rsa". Subteno por RSA-signaturoj kun SHA-256 kaj SHA-512 hashes (rsa-sha2-256/512), kiuj estis subtenataj ekde OpenSSH 7.2, restas senŝanĝa.
Plejofte, ĉesigi subtenon por "ssh-rsa" ne postulos ajnajn manajn agojn de uzantoj, ĉar OpenSSH antaŭe havis la agordon UpdateHostKeys ebligita defaŭlte, kiu aŭtomate migras klientojn al pli fidindaj algoritmoj. Por migrado, la protokola etendo "[retpoŝte protektita]", permesante al la servilo, post aŭtentigo, informi la klienton pri ĉiuj disponeblaj gastigaj ŝlosiloj. En kazo de konekto al gastigantoj kun tre malnovaj versioj de OpenSSH ĉe la kliento, vi povas elekte redoni la kapablon uzi "ssh-rsa" subskribojn aldonante al ~/.ssh/config: Gastigi old_hostname HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms + ssh-rsa
La nova versio ankaŭ solvas sekurecan problemon kaŭzitan de sshd, komencante kun OpenSSH 6.2, ne ĝuste pravalorigante la uzantgrupon dum plenumado de komandoj specifitaj en la direktivoj AuthorizedKeysCommand kaj AuthorizedPrincipalsCommand. Ĉi tiuj direktivoj laŭsupoze permesis ke komandoj estu rulitaj sub malsama uzanto, sed fakte ili heredis la liston de grupoj uzataj dum rulado de sshd. Eble, ĉi tiu konduto, en la ĉeesto de certaj sistemaj agordoj, permesis al la lanĉita prizorganto akiri pliajn privilegiojn sur la sistemo.
La nova eldonnoto ankaŭ inkluzivas averton, ke scp defaŭlte al SFTP anstataŭ la hereda protokolo SCP/RCP. SFTP uzas pli antaŭvideblajn nomtraktadmetodojn kaj ne uzas ŝelprilaboradon de glob-padronoj en dosiernomoj sur la flanko de la alia gastiganto, kiu kreas sekurecproblemojn. Precipe, kiam oni uzas SCP kaj RCP, la servilo decidas kiujn dosierojn kaj dosierujojn sendi al la kliento, kaj la kliento nur kontrolas la ĝustecon de la revenitaj objektonomoj, kiuj, sen taŭga kontrolo ĉe la kliento, permesas la servilo por transdoni aliajn dosiernomojn kiuj diferencas de tiuj petitaj. La SFTP-protokolo ne havas ĉi tiujn problemojn, sed ne subtenas la vastiĝon de specialaj vojoj kiel "~/". Por trakti ĉi tiun diferencon, la antaŭa eldono de OpenSSH enkondukis novan SFTP-protokoletendaĵon al la ~/ kaj ~uzanto/ vojoj en la SFTP-servila efektivigo.
fonto: opennet.ru