Después de cuatro meses de desarrollo lanzamiento , una implementación abierta de cliente y servidor para trabajar con los protocolos SSH 2.0 y SFTP.
La mejora clave en la versión OpenSSH 8.2 fue la posibilidad de utilizar la autenticación de dos factores mediante dispositivos que soportan el protocolo , desarrollado por la alianza . U2F permite crear tokens de hardware baratos para confirmar la presencia física del usuario, que interactúan a través de USB, Bluetooth o NFC. Estos dispositivos se promueven como un medio para la autenticación de dos factores en sitios web, ya son compatibles con los principales navegadores y son fabricados por varias empresas, incluyendo Yubico, Feitian, Thetis y Kensington.
Para interactuar con dispositivos que confirman la presencia del usuario, OpenSSH ha añadido nuevos tipos de claves "ecdsa-sk" y "ed25519-sk", que utilizan algoritmos de firma digital ECDSA y Ed25519, junto con el hash SHA-256. Los procedimientos de interacción con los tokens se han movido a una biblioteca intermedia, que se carga de manera similar a la biblioteca para soportar PKCS#11 y es un contenedor sobre la biblioteca , que proporciona medios para la comunicación con los tokens a través de USB (soporta los protocolos FIDO U2F/CTAP 1 y FIDO 2.0/CTAP 2). La biblioteca intermedia libsk-libfido2 preparada por los desarrolladores de OpenSSH está integrada en libfido2, al igual que para OpenBSD.
Para la autenticación y generación de claves es necesario especificar en la configuración el parámetro "SecurityKeyProvider" o establecer la variable de entorno SSH_SK_PROVIDER, indicando la ruta a la biblioteca externa libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). Es posible compilar openssh con soporte integrado para la biblioteca intermedia (—with-security-key-builtin), en este caso es necesario establecer el parámetro "SecurityKeyProvider=internal".
A continuación, se debe ejecutar "ssh-keygen -t ecdsa-sk" o, si las claves ya han sido creadas y configuradas, conectarse al servidor usando "ssh". Al ejecutar ssh-keygen, el par de claves generado se guardará en "~/.ssh/id_ecdsa_sk" y puede ser utilizado de manera similar a otras claves.
La clave pública (id_ecdsa_sk.pub) debe copiarse en el servidor en el archivo authorized_keys. En el lado del servidor, solo se verifica la firma digital, mientras que la interacción con los tokens se realiza en el lado del cliente (no es necesario instalar libsk-libfido2 en el servidor, pero el servidor debe soportar el tipo de claves «ecdsa-sk»). La clave privada generada (id_ecdsa_sk) es esencialmente un descriptor de clave que solo forma la clave real en combinación con una secuencia secreta almacenada en el token U2F. Si la clave id_ecdsa_sk cae en manos de un atacante, también necesitará acceder al token físico para pasar la autenticación, ya que la clave privada almacenada en el archivo id_ecdsa_sk es inútil sin él.
Además, por defecto, al realizar cualquier operación con claves (tanto al generarlas como al autenticar) se requiere una confirmación local de la presencia física del usuario, por ejemplo, se le pide tocar el sensor en el token, lo que dificulta los ataques remotos a los sistemas con token conectado. Como otra capa de protección, al iniciar ssh-keygen también se puede establecer una contraseña para acceder al archivo de clave.
En la nueva versión de OpenSSH también se ha anunciado la próxima desactivación de los algoritmos que utilizan hashes SHA-1, debido a en la eficacia de los ataques de colisión con un prefijo específico (el costo de generar una colisión se estima en aproximadamente 45 mil dólares). En una de las próximas versiones, se planea desactivar por defecto la posibilidad de utilizar el algoritmo de firma digital de clave pública «ssh-rsa», mencionado en el RFC original para el protocolo SSH y que sigue siendo ampliamente utilizado en la práctica (para verificar la implementación de ssh-rsa en sus sistemas, se puede intentar conectarse por ssh con la opción «-oHostKeyAlgorithms=-ssh-rsa»).
Para suavizar la transición a nuevos algoritmos en OpenSSH, en una de las siguientes versiones se activará por defecto la configuración UpdateHostKeys, que permitirá a los clientes migrar automáticamente a algoritmos más seguros. Entre los algoritmos recomendados para la migración se mencionan rsa-sha2-256/512 basados en el RFC8332 RSA SHA-2 (soportado desde OpenSSH 7.2 y utilizado por defecto), ssh-ed25519 (soportado desde OpenSSH 6.5) y ecdsa-sha2-nistp256/384/521 basados en el RFC5656 ECDSA (soportado desde OpenSSH 5.7).
En la versión OpenSSH 8.2, la posibilidad de conexión utilizando «ssh-rsa» se ha mantenido, pero este algoritmo ha sido eliminado de la lista CASignatureAlgorithms, que define los algoritmos permitidos para la firma digital de nuevos certificados. De manera similar, el algoritmo diffie-hellman-group14-sha1 ha sido eliminado de los algoritmos de intercambio de claves soportados por defecto. Se señala que el uso de SHA-1 en certificados implica un riesgo adicional, ya que un atacante tiene tiempo ilimitado para encontrar colisiones para un certificado existente, mientras que el tiempo de ataque a las claves de host está limitado por el tiempo de conexión (LoginGraceTime).
Al ejecutar ssh-keygen, ahora se utiliza por defecto el algoritmo rsa-sha2-512, que es soportado desde OpenSSH 7.2, lo que puede causar problemas de compatibilidad al intentar procesar certificados firmados en OpenSSH 8.2 en sistemas con versiones antiguas de OpenSSH (para evitar el problema al generar firmas, se puede especificar explícitamente «ssh-keygen -t ssh-rsa» o utilizar los algoritmos ecdsa-sha2-nistp256/384/521, soportados desde OpenSSH 5.7).
Otros cambios:
- Se ha añadido la directiva Include en sshd_config, que permite incluir el contenido de otros archivos en la posición actual del archivo de configuración (al especificar el nombre del archivo, se permite el uso de máscaras glob).
- Se ha añadido la opción «no-touch-required» en ssh-keygen, que desactiva la necesidad de confirmación física para acceder al token al generar una clave.
- Se ha añadido la directiva PubkeyAuthOptions en sshd_config, que combina diferentes opciones relacionadas con la autenticación de clave pública. En la actualidad, solo se soporta la bandera «no-touch-required» para omitir el chequeo de presencia física al autorizar mediante un token. De manera similar, se ha añadido la opción «no-touch-required» en el archivo authorized_keys.
- Se ha añadido la opción «-O write-attestation=/path» en ssh-keygen, que permite escribir certificados de atestación adicionales de FIDO al generar claves. OpenSSH actualmente no utiliza estos certificados, pero en el futuro pueden ser utilizados para verificar que la clave esté almacenada en un hardware confiable.
- En la configuración de ssh y sshd, ahora es posible establecer el modo de priorización del tráfico a través de la directiva IPQoS. (Comportamiento de esfuerzo inferior por salto);
- En ssh, al establecer el valor «AddKeysToAgent=yes», si la clave no contiene un campo de comentario, será añadida al ssh-agent indicando como comentario la ruta de la clave.
ssh-keygen y ssh-agent ahora también utilizan etiquetas PKCS#11 y el nombre del sujeto X.509 como comentarios en la clave, en lugar del camino a la biblioteca; - ssh-keygen ha añadido la capacidad de exportar PEM para claves DSA y ECDSA;
- Se ha añadido un nuevo archivo ejecutable ssh-sk-helper, utilizado para aislar la biblioteca de acceso a los tokens FIDO/U2F;
- Se ha añadido una opción de compilación «—with-zlib» en ssh y sshd para compilar con soporte para la biblioteca zlib;
- De acuerdo con el requerimiento RFC4253, se ha asegurado que el banner mostrado al conectarse incluya una advertencia sobre el bloqueo de acceso debido al exceder los límites de MaxStartups. Para facilitar el diagnóstico, se ha asegurado que en el encabezado del proceso sshd, visible al usar la utilidad ps, se muestre el número de conexiones autenticadas actualmente y el estado del límite de MaxStartups;
- En ssh y ssh-agent, al invocar el programa que muestra el mensaje de invitación definido a través de $SSH_ASKPASS, se añade ahora un indicador del tipo de invitación: «confirm» — diálogo de confirmación (sí/no), «none» — mensaje informativo, «blank» — solicitud de contraseña;
- Se ha añadido una nueva operación de firma digital en ssh-keygen llamada «find-principals» para buscar en el archivo allowed-signers del usuario, relacionado con la firma digital especificada;
- Se ha mejorado el soporte para el aislamiento del proceso sshd en Linux mediante el mecanismo seccomp: se han prohibido las llamadas al sistema IPC, se han permitido clock_gettime64(), clock_nanosleep_time64 y clock_nanosleep().
Fuente: opennet.ru
