Versió d'OpenSSH 8.5

Després de cinc mesos de desenvolupament, es presenta el llançament d'OpenSSH 8.5, una implementació oberta d'un client i servidor per treballar amb els protocols SSH 2.0 i SFTP.

Els desenvolupadors d'OpenSSH ens van recordar la propera desactivació d'algorismes que utilitzen hash SHA-1 a causa de l'augment de l'eficiència dels atacs de col·lisió amb un prefix determinat (el cost de seleccionar una col·lisió s'estima en aproximadament 50 mil dòlars). En un dels propers llançaments, tenen previst desactivar per defecte la possibilitat d'utilitzar l'algoritme de signatura digital de clau pública "ssh-rsa", que s'esmenta a l'RFC original per al protocol SSH i continua estès a la pràctica.

Per provar l'ús de ssh-rsa als vostres sistemes, podeu provar de connectar-vos mitjançant ssh amb l'opció "-oHostKeyAlgorithms=-ssh-rsa". Al mateix temps, desactivar les signatures digitals “ssh-rsa” per defecte no suposa un abandonament total de l'ús de claus RSA, ja que a més de SHA-1, el protocol SSH permet l'ús d'altres algorismes de càlcul hash. En particular, a més de "ssh-rsa", seguirà sent possible utilitzar els paquets "rsa-sha2-256" (RSA/SHA256) i "rsa-sha2-512" (RSA/SHA512).

Per suavitzar la transició a nous algorismes, OpenSSH 8.5 té la configuració UpdateHostKeys activada de manera predeterminada, que permet als clients canviar automàticament a algorismes més fiables. Amb aquesta configuració, s'habilita una extensió de protocol especial "[protegit per correu electrònic]", permetent al servidor, després de l'autenticació, informar al client sobre totes les claus d'amfitrió disponibles. El client pot reflectir aquestes claus al seu fitxer ~/.ssh/known_hosts, que permet actualitzar les claus de l'amfitrió i facilita el canvi de claus al servidor.

L'ús de UpdateHostKeys està limitat per diverses advertències que es poden eliminar en el futur: la clau s'ha de fer referència a UserKnownHostsFile i no utilitzar-la al GlobalKnownHostsFile; la clau ha d'estar present només sota un nom; no s'ha d'utilitzar un certificat de clau d'amfitrió; en els coneguts_hosts no s'han d'utilitzar màscares per nom d'amfitrió; la configuració VerifyHostKeyDNS ha d'estar desactivada; El paràmetre UserKnownHostsFile ha d'estar actiu.

Els algorismes recomanats per a la migració inclouen rsa-sha2-256/512 basat en RFC8332 RSA SHA-2 (admès des d'OpenSSH 7.2 i utilitzat per defecte), ssh-ed25519 (admès des d'OpenSSH 6.5) i ecdsa-sha2-nistp256/384/521. a RFC5656 ECDSA (admès des d'OpenSSH 5.7).

Altres canvis:

  • Canvis de seguretat:
    • S'ha solucionat una vulnerabilitat causada per tornar a alliberar una àrea de memòria ja alliberada (doble lliure) a ssh-agent. El problema ha estat present des del llançament d'OpenSSH 8.2 i es pot explotar potencialment si un atacant té accés al sòcol ssh-agent al sistema local. El que dificulta l'explotació és que només el root i l'usuari original tenen accés al socket. L'escenari d'atac més probable és que l'agent sigui redirigit a un compte que està controlat per l'atacant o a un amfitrió on l'atacant té accés root.
    • sshd ha afegit protecció contra el pas de paràmetres molt grans amb el nom d'usuari al subsistema PAM, la qual cosa us permet bloquejar vulnerabilitats als mòduls del sistema PAM (Mòdul d'autenticació connectable). Per exemple, el canvi impedeix que sshd s'utilitzi com a vector per explotar una vulnerabilitat arrel descoberta recentment a Solaris (CVE-2020-14871).
  • Canvis de compatibilitat que poden trencar:
    • В ssh и sshd переработан экспериментальный метод обмена ключами, стойкий к подбору на квантовом компьютере. Квантовые компьютеры кардинально быстрее решают задачу разложения натурального числа на простые множители, которая лежит в основе современных асимметричных алгоритмов шифрования и эффективно не решаема на классических процессорах. Используемый метод основан на алгоритме NTRU Prime, разработанном для постквантумных криптосистем, и методе обмена ключами на базе эллиптических кривых X25519. Вместо [protegit per correu electrònic] метод теперь идентифицируется как [protegit per correu electrònic] (l'algorisme sntrup4591761 s'ha substituït per sntrup761).
    • A ssh i sshd, s'ha canviat l'ordre en què s'anuncien els algorismes de signatura digital compatibles. Ara s'ofereix primer l'ED25519 en lloc de l'ECDSA.
    • En ssh i sshd, la configuració dels paràmetres de qualitat de servei TOS/DSCP per a les sessions interactives ara es fa abans d'establir una connexió TCP.
    • El suport de xifrat s'ha interromput a ssh i sshd [protegit per correu electrònic], que és idèntic a aes256-cbc i es va utilitzar abans de l'aprovació de RFC-4253.
    • De manera predeterminada, el paràmetre CheckHostIP està desactivat, el benefici del qual és insignificant, però el seu ús complica significativament la rotació de claus per als amfitrions darrere dels equilibradors de càrrega.
  • La configuració de PerSourceMaxStartups i PerSourceNetBlockSize s'ha afegit a sshd per limitar la intensitat de llançament de controladors en funció de l'adreça del client. Aquests paràmetres us permeten controlar amb més precisió el límit dels llançaments de processos, en comparació amb la configuració general de MaxStartups.
  • S'ha afegit una nova configuració de LogVerbose a ssh i sshd, que us permet augmentar amb força el nivell d'informació de depuració abocada al registre, amb la possibilitat de filtrar per plantilles, funcions i fitxers.
  • A ssh, en acceptar una nova clau d'amfitrió, es mostren tots els noms d'amfitrió i adreces IP associades a la clau.
  • ssh permet que l'opció UserKnownHostsFile=cap per desactivar l'ús del fitxer known_hosts quan s'identifiquen les claus de l'amfitrió.
  • S'ha afegit un paràmetre KnownHostsCommand a ssh_config per a ssh, que us permet obtenir dades de known_hosts de la sortida de l'ordre especificada.
  • S'ha afegit una opció PermitRemoteOpen a ssh_config per a ssh per permetre restringir la destinació quan utilitzeu l'opció RemoteForward amb SOCKS.
  • A ssh per a claus FIDO, es proporciona una sol·licitud de PIN repetida en cas d'error en l'operació de la signatura digital a causa d'un PIN incorrecte i a l'usuari no se li demana un PIN (per exemple, quan no s'han pogut obtenir les dades biomètriques correctes i el dispositiu va tornar a introduir PIN manual).
  • sshd afegeix suport per a trucades de sistema addicionals al mecanisme d'aïllament de processos basat en seccomp-bpf a Linux.
  • S'ha actualitzat la utilitat contrib/ssh-copy-id.

Font: opennet.ru

Afegeix comentari