Lanzamiento de OpenSSH 8.7

Después de cuatro meses de desarrollo, se presentó el lanzamiento de OpenSSH 8.7, una implementación abierta de cliente y servidor para trabajar sobre los protocolos SSH 2.0 y SFTP.

Cambios importantes:

  • Se ha agregado un modo de transferencia de datos experimental a scp utilizando el protocolo SFTP en lugar del protocolo tradicional SCP/RCP. SFTP utiliza métodos de manejo de nombres más predecibles y no utiliza el procesamiento de shell de patrones globales en el otro lado del host, lo que crea problemas de seguridad. Para habilitar SFTP en scp, se propuso el indicador "-s", pero en el futuro está previsto cambiar a este protocolo de forma predeterminada.
  • sftp-server implementa extensiones al protocolo SFTP para expandir las rutas ~/ y ~user/, lo cual es necesario para scp.
  • La utilidad scp ha cambiado el comportamiento al copiar archivos entre dos hosts remotos (por ejemplo, “scp host-a:/ruta host-b:”), que ahora se realiza de forma predeterminada a través de un host local intermedio, como cuando se especifica el “ -Bandera de 3”. Este enfoque le permite evitar pasar credenciales innecesarias al primer host y una triple interpretación de los nombres de los archivos en el shell (en el lado de origen, de destino y del sistema local), y cuando usa SFTP, le permite usar todos los métodos de autenticación al acceder de forma remota. hosts, y no sólo métodos no interactivos. Se agregó la opción "-R" para restaurar el comportamiento anterior.
  • Se agregó la configuración ForkAfterAuthentication a ssh correspondiente al indicador "-f".
  • Se agregó la configuración StdinNull a ssh, correspondiente al indicador "-n".
  • Se ha agregado una configuración SessionType a ssh, a través de la cual puede configurar los modos correspondientes a los indicadores “-N” (sin sesión) y “-s” (subsistema).
  • ssh-keygen le permite especificar un intervalo de validez de clave en archivos de claves.
  • Se agregó el indicador "-Oprint-pubkey" a ssh-keygen para imprimir la clave pública completa como parte de la firma sshsig.
  • En ssh y sshd, tanto el cliente como el servidor se han movido para utilizar un analizador de archivos de configuración más restrictivo que utiliza reglas similares a las de un shell para manejar comillas, espacios y caracteres de escape. El nuevo analizador tampoco ignora suposiciones hechas anteriormente, como omitir argumentos en las opciones (por ejemplo, la directiva DenyUsers ya no puede dejarse vacía), comillas abiertas y especificar múltiples caracteres =.
  • Cuando se utilizan registros DNS SSHFP al verificar claves, ssh ahora verifica todos los registros coincidentes, no solo aquellos que contienen un tipo específico de firma digital.
  • En ssh-keygen, al generar una clave FIDO con la opción -Ochallenge, la capa incorporada ahora se usa para hash, en lugar de libfido2, lo que permite el uso de secuencias de desafío mayores o menores de 32 bytes.
  • En sshd, al procesar directivas de entorno="..." en archivos autorizados_keys, ahora se acepta la primera coincidencia y hay un límite de 1024 nombres de variables de entorno.

Los desarrolladores de OpenSSH también advirtieron sobre la descomposición de los algoritmos que utilizan 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 la próxima versión, planeamos deshabilitar de forma predeterminada la capacidad de utilizar el algoritmo de firma digital de clave pública "ssh-rsa", que se mencionó en el RFC original para el protocolo SSH y sigue siendo ampliamente utilizado 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 anteriormente tenía habilitada de forma predeterminada la configuración UpdateHostKeys, 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).

Fuente: opennet.ru

Añadir un comentario