Después de cinco meses de desarrollo, se presenta el lanzamiento de OpenSSH 8.5, una implementación abierta de cliente y servidor para trabajar sobre los protocolos SSH 2.0 y SFTP.
Los desarrolladores de OpenSSH nos recordaron el próximo desmantelamiento de algoritmos que usan hashes SHA-1 debido a la mayor eficiencia de los ataques de colisión con un prefijo determinado (el costo de seleccionar una colisión se estima en aproximadamente 50 mil dólares). En una de las próximas versiones, planean desactivar de forma predeterminada la capacidad de utilizar el algoritmo de firma digital de clave pública "ssh-rsa", que se menciona en el RFC original para el protocolo SSH y sigue estando muy extendido en la práctica.
Para probar el uso de ssh-rsa en sus sistemas, puede intentar conectarse vía ssh con la opción “-oHostKeyAlgorithms=-ssh-rsa”. Al mismo tiempo, deshabilitar las firmas digitales "ssh-rsa" de forma predeterminada no significa abandonar por completo el uso de claves RSA, ya que además de SHA-1, el protocolo SSH permite el uso de otros algoritmos de cálculo hash. En particular, además de “ssh-rsa”, seguirá siendo posible utilizar los paquetes “rsa-sha2-256” (RSA/SHA256) y “rsa-sha2-512” (RSA/SHA512).
Para facilitar la transición a nuevos algoritmos, OpenSSH 8.5 tiene la configuración UpdateHostKeys habilitada de forma predeterminada, lo que permite a los clientes cambiar automáticamente a algoritmos más confiables. Con esta configuración, se habilita una extensión de protocolo especial "[email protected]", lo que permite al servidor, después de la autenticación, informar al cliente sobre todas las claves de host disponibles. El cliente puede reflejar estas claves en su archivo ~/.ssh/known_hosts, lo que permite actualizar las claves del host y facilita el cambio de claves en el servidor.
El uso de UpdateHostKeys está limitado por varias advertencias que pueden eliminarse en el futuro: se debe hacer referencia a la clave en UserKnownHostsFile y no usarse en GlobalKnownHostsFile; la clave debe estar presente bajo un solo nombre; no se debe utilizar un certificado de clave de host; enknown_hosts no se deben utilizar máscaras por nombre de host; la configuración VerifyHostKeyDNS debe estar deshabilitada; El parámetro UserKnownHostsFile debe estar activo.
Los algoritmos recomendados para la migración incluyen 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) y basado en ecdsa-sha2-nistp256/384/521 en RFC5656 ECDSA (compatible desde OpenSSH 5.7).
Otros cambios:
- Cambios de seguridad:
- Se ha corregido en ssh-agent una vulnerabilidad causada al volver a liberar un área de memoria ya liberada (doble liberación). El problema ha estado presente desde el lanzamiento de OpenSSH 8.2 y potencialmente puede explotarse si un atacante tiene acceso al socket del agente ssh en el sistema local. Lo que dificulta la explotación es que sólo el root y el usuario original tienen acceso al socket. El escenario de ataque más probable es que el agente sea redirigido a una cuenta controlada por el atacante o a un host donde el atacante tenga acceso raíz.
- sshd ha agregado protección contra el paso de parámetros muy grandes con el nombre de usuario al subsistema PAM, lo que le permite bloquear vulnerabilidades en los módulos del sistema PAM (Módulo de autenticación conectable). Por ejemplo, el cambio evita que sshd se utilice como vector para explotar una vulnerabilidad raíz descubierta recientemente en Solaris (CVE-2020-14871).
- Cambios de compatibilidad potencialmente disruptivos:
- En ssh y sshd, se ha rediseñado un método experimental de intercambio de claves que es resistente a las adivinanzas en una computadora cuántica. Las computadoras cuánticas son radicalmente más rápidas a la hora de resolver el problema de descomponer un número natural en factores primos, lo que subyace a los modernos algoritmos de cifrado asimétrico y no puede resolverse eficazmente en los procesadores clásicos. El método utilizado se basa en el algoritmo NTRU Prime, desarrollado para criptosistemas poscuánticos, y el método de intercambio de claves de curva elíptica X25519. En lugar de [email protected] el método ahora se identifica como [email protected] (El algoritmo sntrup4591761 ha sido reemplazado por sntrup761).
- En ssh y sshd, se cambió el orden en que se anuncian los algoritmos de firma digital admitidos. Ahora se ofrece primero ED25519 en lugar de ECDSA.
- En ssh y sshd, la configuración de los parámetros de calidad de servicio TOS/DSCP para sesiones interactivas ahora se realiza antes de establecer una conexión TCP.
- La compatibilidad con cifrado ha sido descontinuada en ssh y sshd [email protected], que es idéntico a aes256-cbc y se utilizó antes de que se aprobara RFC-4253.
- De forma predeterminada, el parámetro CheckHostIP está deshabilitado, cuyo beneficio es insignificante, pero su uso complica significativamente la rotación de claves para los hosts detrás de los balanceadores de carga.
- Se agregaron las configuraciones PerSourceMaxStartups y PerSourceNetBlockSize a sshd para limitar la intensidad del inicio de controladores según la dirección del cliente. Estos parámetros le permiten controlar con mayor precisión el límite de inicios de procesos, en comparación con la configuración general de MaxStartups.
- Se ha agregado una nueva configuración LogVerbose a ssh y sshd, que le permite elevar con fuerza el nivel de información de depuración volcada en el registro, con la capacidad de filtrar por plantillas, funciones y archivos.
- En ssh, al aceptar una nueva clave de host, se muestran todos los nombres de host y direcciones IP asociados con la clave.
- ssh permite que la opción UserKnownHostsFile=none deshabilite el uso del archivoknown_hosts al identificar claves de host.
- Se agregó una configuración KnownHostsCommand a ssh_config para ssh, lo que le permite obtener datos deknown_hosts a partir de la salida del comando especificado.
- Se agregó una opción PermitRemoteOpen a ssh_config para ssh para permitirle restringir el destino al usar la opción RemoteForward con SOCKS.
- En ssh para claves FIDO, se proporciona una solicitud de PIN repetida en caso de una falla en la operación de firma digital debido a un PIN incorrecto y al usuario no se le solicita un PIN (por ejemplo, cuando no se pudieron obtener los datos biométricos correctos y el dispositivo volvió a la entrada manual de PIN).
- sshd agrega soporte para llamadas adicionales al sistema al mecanismo de aislamiento de procesos basado en seccomp-bpf en Linux.
- La utilidad contrib/ssh-copy-id ha sido actualizada.
Fuente: opennet.ru