Y no ha pasado medio año: se ha lanzado el lanzamiento de OpenSSH 8.5. Detalles sobre el nuevo producto



Después de cinco meses de desarrollo, la liberación de OpenSSH 8.5 es puesto en libertad, una implementación abierta de un cliente y el servidor para trabajar con los protocolos SSH 2.0 y SFTP. Los desarrolladores anunciaron la traducción en el futuro de algoritmos que usan hashes SHA-1 a la categoría de obsoletos. El problema es que la efectividad de los ataques de colisión con un prefijo determinado aumenta constantemente. Al mismo tiempo, el costo de seleccionar una colisión cuesta alrededor de $ 50 000.



En un futuro cercano, los desarrolladores prometen deshabilitar la capacidad de usar el algoritmo de firma digital usando la clave pública "ssh-rsa" por defecto. Todavía está muy extendido hoy.



Para comprobar si esta clave se utiliza en su propio sistema, debe intentar conectarse a través de ssh con la opción "-oHostKeyAlgorithms = -ssh-rsa". Un punto importante: deshabilitar este tipo de firma digital por defecto no es un rechazo total al uso de claves RSA. El problema es que, además de SHA-1, el protocolo SSH permite otros algoritmos para calcular hashes. Entre otras posibilidades, los desarrolladores dejarán el uso de los paquetes "rsa-sha2-256" (RSA / SHA256) y "rsa-sha2-512" (RSA / SHA512).



Para simplificar la transición a nuevos algoritmos, la nueva versión incluye de forma predeterminada configurando UpdateHostKeys. Es ella quien transfiere clientes a nuevos algoritmos. La función activa una extensión de protocolo especial "hostkeys@openssh.com", que permite al servidor informar al cliente sobre todas las claves de host disponibles inmediatamente después de pasar la autenticación. El cliente puede reflejar estas claves en el archivo ~ / .ssh / known_hosts, lo que hace posible organizar la actualización de las claves de host, facilitando el cambio de claves en el servidor.



Cabe señalar que el uso de UpdateHostKeys es posible con varios matices:



  • debe mencionarse en UserKnownHostsFile y no usarse en GlobalKnownHostsFile;
  • la clave debe estar presente bajo un solo nombre,
  • no se debe utilizar el certificado de clave de host;
  • hosts_conocidos no deben usar máscaras de nombre de host;
  • la configuración VerifyHostKeyDNS debe estar deshabilitada;
  • el parámetro UserKnownHostsFile debe estar activo.


Entre los algoritmos que los desarrolladores mencionan como recomendados para la migración:



  • rsa-sha2-256 / 512 basado en RFC8332 RSA SHA-2 (compatible desde OpenSSH 7.2 y utilizado de forma predeterminada);
  • ssh-ed25519 (compatible desde OpenSSH 6.5);
  • ecdsa-sha2-nistp256 / 384/521 basado en RFC5656 ECDSA (compatible desde OpenSSH 5.7).




Detalles de los cambios en la nueva versión



Por supuesto, los desarrolladores han agregado muchas otras características que cubren varias categorías.



Seguridad:



  • ssh-agent, . OpenSSH 8.2. ssh-agent . , , . , , , root-.
  • sshd -. PAM (Pluggable Authentication Module). sshd root- Solaris (CVE-2020-14871).


:



  • ssh sshd , . , . , . , . NTRU Prime, , X25519. sntrup4591761x25519-sha512@tinyssh.org sntrup761x25519-sha512@openssh.com ( sntrup4591761 sntrup761).
  • ssh sshd . ECDSA ED25519.
  • TOS/DSCP TCP-.
  • ijndael-cbc@lysator.liu.se, aes256-cbc RFC-4253, .
  • CheckHostIP. , .






  • sshd PerSourceMaxStartups PerSourceNetBlockSize . .
  • ssh sshd LogVerbose, , , .
  • ssh IP-, . .
  • ssh UserKnownHostsFile=none known_hosts .
  • ssh-config KnownHostsCommand, known_hosts .
  • PermitRemoteOpen, RemoteForward SOCKS.
  • ssh FIDO PIN - PIN PIN . , , PIN.
  • contrib/ssh-copy-id.





All Articles