{"id":101069,"date":"2021-08-20T22:22:44","date_gmt":"2021-08-20T20:22:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/reliz-openssh-8-7"},"modified":"2021-08-20T22:22:44","modified_gmt":"2021-08-20T20:22:44","slug":"reliz-openssh-8-7","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/reliz-openssh-8-7","title":{"rendered":"Lanzamiento de OpenSSH 8.7","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Despu\u00e9s de cuatro meses de desarrollo, se presenta la versi\u00f3n OpenSSH 8.7, una implementaci\u00f3n abierta del cliente y servidor para trabajar con los protocolos SSH 2.0 y SFTP. <\/p>\n
Principales cambios: <\/p>\n
\n
Se ha a\u00f1adido un modo experimental de transferencia de datos en scp utilizando el protocolo SFTP en lugar del protocolo tradicional SCP\/RCP. SFTP emplea m\u00e9todos de procesamiento de nombres m\u00e1s predecibles y no utiliza el procesamiento de patrones glob a trav\u00e9s del shell en el otro host, lo que genera problemas de seguridad. Para habilitar SFTP en scp, se ha propuesto la opci\u00f3n \u00ab-s\u00bb, aunque en el futuro se planea migrar a este protocolo por defecto.\n
En sftp-server se han implementado extensiones del protocolo SFTP para revelar las rutas ~\/ y ~user\/, lo cual es necesario para scp.\n
Se ha modificado el comportamiento en la utilidad scp al copiar archivos entre dos hosts remotos (por ejemplo, \u00abscp host-a:\/path host-b:\u00bb), que ahora se realiza por defecto a trav\u00e9s de un host local intermedio, como si se especificara la opci\u00f3n \u00ab-3\u00bb. Este enfoque permite evitar la transmisi\u00f3n de credenciales innecesarias al primer host y la triple interpretaci\u00f3n de los nombres de archivos en el shell (en el lado del origen, receptor y sistema local), y tambi\u00e9n permite utilizar todos los m\u00e9todos de autenticaci\u00f3n al acceder a hosts remotos, y no solo m\u00e9todos no interactivos al usar SFTP. Se ha a\u00f1adido la opci\u00f3n \u00ab-R\u00bb para restaurar el comportamiento anterior.\n
Se ha a\u00f1adido la configuraci\u00f3n ForkAfterAuthentication en ssh, correspondiente a la opci\u00f3n \u00ab-f\u00bb.\n
Se ha a\u00f1adido la configuraci\u00f3n StdinNull en ssh, correspondiente a la opci\u00f3n \u00ab-n\u00bb.\n
Se ha a\u00f1adido la configuraci\u00f3n SessionType en ssh, que permite establecer modos correspondientes a las opciones \u00ab-N\u00bb (sin sesi\u00f3n) y \u00ab-s\u00bb (subsystem).\n
En ssh-keygen se permite especificar la duraci\u00f3n de la clave en los archivos de clave.\n
Se ha a\u00f1adido la opci\u00f3n \u00ab-Oprint-pubkey\u00bb en ssh-keygen para mostrar la clave p\u00fablica completa en la firma de sshsig.\n
En ssh y sshd, tanto el cliente como el servidor, se ha pasado a un parser de archivo de configuraci\u00f3n m\u00e1s estricto, que utiliza reglas de procesamiento similares al shell para comillas, espacios y caracteres de escape. Este nuevo parser tambi\u00e9n no omite asunciones previamente existentes, como el omitir argumentos en las opciones (por ejemplo, ahora no se puede dejar una directiva DenyUsers vac\u00eda), comillas sin cerrar y la especificaci\u00f3n de m\u00faltiples caracteres \u00ab=\u00bb.\n
Al usar registros DNS SSHFP para la verificaci\u00f3n de claves, ssh ahora verifica todos los registros coincidentes, no solo aquellos que contienen un tipo espec\u00edfico de firma digital.\n
En ssh-keygen, al generar una clave FIDO con la opci\u00f3n -Ochallenge para el hashing, se utiliza ahora una capa integrada en lugar de la biblioteca libfido2, lo que permite usar secuencias de desaf\u00edo de m\u00e1s o menos de 32 bytes.\n
En sshd, al procesar la directiva environment=\u00ab\u2026\u00bb en los archivos authorized_keys, ahora se acepta la primera coincidencia y se aplica un l\u00edmite de 1024 nombres de variables de entorno. <\/ul>\n
Los desarrolladores de OpenSSH tambi\u00e9n han advertido sobre la transici\u00f3n de ciertos algoritmos que utilizan hashes SHA-1 a la categor\u00eda de obsoletos, debido al aumento de la efectividad de los ataques de colisi\u00f3n con prefijo espec\u00edfico (el costo de generar una colisi\u00f3n se estima en aproximadamente 50 mil d\u00f3lares). En la pr\u00f3xima versi\u00f3n, se planea desactivar por defecto la posibilidad de usar el algoritmo de firma digital con clave p\u00fablica \u00abssh-rsa\u00bb, que se menciona en el RFC original del protocolo SSH y sigue siendo ampliamente utilizado en la pr\u00e1ctica. <\/p>\n
Para verificar el uso de ssh-rsa en sus sistemas, puede intentar conectarse por ssh con la opci\u00f3n \u00ab-oHostKeyAlgorithms=-ssh-rsa\u00bb. Sin embargo, la desactivaci\u00f3n por defecto de las firmas digitales \u00abssh-rsa\u00bb no significa un rechazo total del uso de claves RSA, ya que adem\u00e1s de SHA-1, el protocolo SSH permite el uso de otros algoritmos de hashing. En particular, adem\u00e1s de \u00abssh-rsa\u00bb, seguir\u00e1 siendo posible utilizar los pares \u00abrsa-sha2-256\u00bb (RSA\/SHA256) y \u00abrsa-sha2-512\u00bb (RSA\/SHA512). <\/p>\n