Después de cinco meses de desarrollo lanzamiento , una implementación abierta de cliente y servidor para trabajar con los protocolos SSH 2.0 y SFTP.
Principales cambios:
- Se ha añadido soporte experimental para el método de intercambio de claves resistente a ataques de computadoras cuánticas en ssh y sshd. Las computadoras cuánticas resuelven drásticamente más rápido el problema de descomposición de un número natural en factores primos, que es la base de los algoritmos de cifrado asimétrico modernos y que no se puede resolver de forma efectiva en procesadores clásicos. El método propuesto se basa en el algoritmo (función ntrup4591761), diseñado para criptosistemas postcuánticos, y el método de intercambio de claves basado en curvas elípticas X25519;
- Se ha eliminado el soporte para la sintaxis obsoleta «host/port» en las directivas ListenAddress y PermitOpen de sshd, implementada en 2001 como alternativa a «host:port» para simplificar el trabajo con IPv6. En la actualidad, para IPv6 se ha consolidado la sintaxis «[::1]:22», y «host/port» a menudo se confunde con la indicación de subred (CIDR);
- Se ha implementado soporte para claves en tokens PKCS#11;
- En ssh-keygen, el tamaño de la clave RSA se ha incrementado por defecto a 3072 bits, de acuerdo con las nuevas recomendaciones de NIST;
- Se permite en ssh el uso de la configuración «PKCS11Provider=none» para sobrescribir la directiva PKCS11Provider definida en ssh_config;
- Se ha proporcionado en sshd el registro de situaciones en las que la conexión se cierra al intentar ejecutar comandos bloqueados por la restricción «ForceCommand=internal-sftp» en sshd_config;
- En ssh, al mostrar el prompt de confirmación al recibir una nueva clave de host, en lugar de la respuesta «yes», ahora se acepta la huella dactilar correcta de la clave (en respuesta a la invitación de confirmar la conexión, el usuario puede copiar manualmente el hash de referencia obtenido del portapapeles, para no tener que compararlo manualmente);
- En ssh-keygen, se ha implementado el aumento automático del número de secuencia en el certificado al crear firmas digitales para varios certificados desde la línea de comandos;
- Se ha añadido una nueva opción «-J» en scp y sftp, equivalente a la configuración ProxyJump;
- Se ha añadido el manejo de la opción de línea de comandos «-v» en ssh-agent, ssh-pkcs11-helper y ssh-add para aumentar la información en la salida (cuando se especifica, esta opción se transmite a los procesos secundarios, por ejemplo, cuando ssh-agent invoca a ssh-pkcs11-helper);
- Se añadió la opción «-T» a ssh-add para probar la idoneidad de las claves en ssh-agent para realizar operaciones de creación y verificación de firmas digitales;
- Se implementó el soporte para la extensión del protocolo «lsetstat at openssh.com» en sftp-server, que añade soporte para la operación SSH2_FXP_SETSTAT en SFTP, pero sin seguir enlaces simbólicos;
- Se añadió la opción «-h» a sftp para ejecutar comandos chown/chgrp/chmod con solicitudes que no utilicen enlaces simbólicos;
- Se aseguró que la variable de entorno $SSH_CONNECTION esté disponible para PAM en sshd;
- Para sshd, se añadió el modo de coincidencia «Match final» en ssh_config, similar a «Match canonical», pero que no requiere la normalización del nombre del host;
- Se añadió soporte para el prefijo ‘@’ en sftp para desactivar la traducción de la salida de comandos ejecutados en modo por lotes;
- Al mostrar el contenido del certificado utilizando el comando
«ssh-keygen -Lf /path/certificate» ahora se muestra el algoritmo utilizado por la autoridad de certificación para certificar el certificado; - Mejorada la compatibilidad con el entorno Cygwin, como por ejemplo, permitiendo la comparación de nombres de grupos y usuarios sin distinción de mayúsculas y minúsculas. El proceso sshd en el puerto para Cygwin ha sido cambiado a cygsshd para evitar conflictos con el puerto OpenSSH proporcionado por Microsoft;
- Se añadió la capacidad de compilación con la rama experimental OpenSSL 3.x;
- Corregido (CVE-2019-6111) en la implementación de la utilidad scp, que permite sobrescribir archivos arbitrarios en el directorio objetivo del cliente al conectarse a un servidor controlado por un atacante. El problema radica en que al utilizar scp, el servidor decide qué archivos y directorios enviar al cliente, y el cliente solo verifica la validez de los nombres de los objetos devueltos. La verificación en el lado del cliente se limita a bloquear el acceso más allá del directorio actual («.. /»), pero no tiene en cuenta la transferencia de archivos con nombres distintos a los originalmente solicitados. En caso de copia recursiva (-r), además de los nombres de archivos, también se pueden manipular los nombres de los subdirectorios. Por ejemplo, al copiar archivos al directorio personal, un servidor controlado por atacantes puede devolver en lugar de los archivos solicitados, archivos con nombres .bash_aliases o .ssh/authorized_keys, y serán guardados por la utilidad scp en el directorio personal del usuario.
En la nueva versión, se ha añadido una verificación de la correspondencia entre los nombres de archivos solicitados y los entregados por el servidor en la herramienta scp, que se realiza del lado del cliente. Sin embargo, pueden surgir problemas con el manejo de las máscaras, ya que los caracteres de expansión de máscaras pueden procesarse de manera diferente en el servidor y el cliente. En caso de que, debido a tales diferencias, el cliente deje de aceptar archivos en scp, se ha añadido la opción "-T", que permite deshabilitar la verificación del lado del cliente. Para solucionar completamente el problema, se requiere una revisión conceptual del protocolo scp, que por sí mismo ya está obsoleto, por lo que se recomienda utilizar protocolos más modernos, como sftp y rsync.
Fuente: opennet.ru
