Después de cuatro meses de desarrollo relizar , una implementación abierta de cliente y servidor para trabajar a través de los protocolos SSH 2.0 y SFTP.
Una mejora clave en el lanzamiento de OpenSSH 8.2 fue la capacidad de utilizar autenticación de dos factores utilizando dispositivos que admitan el protocolo. , desarrollado por la alianza . U2F permite la creación de tokens hardware de bajo coste para verificar la presencia física del usuario, interactuando con él vía USB, Bluetooth o NFC. Estos dispositivos se promocionan como un medio de autenticación de dos factores en sitios web, ya son compatibles con los principales navegadores y son producidos por varios fabricantes, incluidos Yubico, Feitian, Thetis y Kensington.
Para interactuar con dispositivos que confirman la presencia del usuario, se han agregado a OpenSSH nuevos tipos de claves “ecdsa-sk” y “ed25519-sk”, que utilizan los algoritmos de firma digital ECDSA y Ed25519, combinados con el hash SHA-256. Los procedimientos para interactuar con tokens se colocan en una biblioteca intermedia, que se carga de manera similar a la biblioteca para compatibilidad con PKCS#11 y es un contenedor encima de la biblioteca. , que proporciona herramientas para comunicarse con tokens a través de USB (se admiten los protocolos FIDO U2F/CTAP 1 y FIDO 2.0/CTAP 2). Biblioteca intermedia libsk-libfido2 preparada por desarrolladores de OpenSSH en el núcleo libfido2, así como para OpenBSD.
Para autenticar y generar una clave, debe especificar el parámetro "SecurityKeyProvider" en la configuración o configurar la variable de entorno SSH_SK_PROVIDER, indicando la ruta a la biblioteca externa libsk-libfido2.so (exportar SSH_SK_PROVIDER=/path/to/libsk-libfido2. entonces). Es posible crear openssh con soporte integrado para la biblioteca de capas (--with-security-key-builtin), en este caso es necesario configurar el parámetro “SecurityKeyProvider=internal”.
A continuación, debe ejecutar "ssh-keygen -t ecdsa-sk" o, si las claves ya se han creado y configurado, conectarse al servidor mediante "ssh". Cuando ejecuta ssh-keygen, el par de claves generado se guardará en “~/.ssh/id_ecdsa_sk” y se puede usar de manera similar a otras claves.
La clave pública (id_ecdsa_sk.pub) debe copiarse al servidor en el archivo autorizado_keys. En el lado del servidor, solo se verifica la firma digital y 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 admitir el tipo de clave “ecdsa-sk”) . La clave privada generada (id_ecdsa_sk) es esencialmente un identificador de clave, que forma una clave real solo en combinación con la secuencia secreta almacenada en el lado del token U2F. Si la clave id_ecdsa_sk cae en manos de un atacante, para pasar la autenticación también necesitará obtener acceso al token de hardware, sin el cual la clave privada almacenada en el archivo id_ecdsa_sk es inútil.
Además, de forma predeterminada, al realizar cualquier operación con claves (tanto durante la generación como durante la autenticación), se requiere la confirmación local de la presencia física del usuario, por ejemplo, se propone tocar el sensor del token, lo que dificulta Realizar ataques remotos a sistemas con un token conectado. Como otra línea de defensa, también se puede especificar una contraseña durante la fase de inicio de ssh-keygen para acceder al archivo clave.
La nueva versión de OpenSSH también anunció la próxima obsolescencia de los algoritmos que utilizan hashes SHA-1 debido a la efectividad de los ataques de colisión con un prefijo determinado (el costo de seleccionar una colisión se estima en aproximadamente 45 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”).
Para facilitar la transición a nuevos algoritmos en OpenSSH, en una versión futura, la configuración UpdateHostKeys estará habilitada de forma predeterminada, lo que migrará automáticamente a los clientes a algoritmos más confiables. 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).
En OpenSSH 8.2, la capacidad de conectarse usando “ssh-rsa” todavía está disponible, pero este algoritmo se eliminó de la lista CASignatureAlgorithms, que define los algoritmos permitidos para firmar digitalmente nuevos certificados. De manera similar, el algoritmo diffie-hellman-group14-sha1 se eliminó de los algoritmos de intercambio de claves predeterminados admitidos. Cabe señalar que el uso de SHA-1 en certificados está asociado con un riesgo adicional, ya que el atacante tiene un tiempo ilimitado para buscar una colisión para un certificado existente, mientras que el tiempo de ataque a las claves del host está limitado por el tiempo de espera de la conexión (LoginGraceTime ).
La ejecución de ssh-keygen ahora utiliza de forma predeterminada el algoritmo rsa-sha2-512, que es compatible desde OpenSSH 7.2, lo que puede crear problemas de compatibilidad al intentar procesar certificados firmados en OpenSSH 8.2 en sistemas que ejecutan versiones anteriores de OpenSSH (para solucionar el problema cuando Cuándo Al generar una firma, puede especificar explícitamente “ssh-keygen -t ssh-rsa” o usar los algoritmos ecdsa-sha2-nistp256/384/521, compatibles desde OpenSSH 5.7).
Otros cambios:
- Se ha agregado una directiva Incluir a sshd_config, que le permite incluir el contenido de otros archivos en la posición actual del archivo de configuración (se pueden usar máscaras globales al especificar el nombre del archivo);
- Se agregó la opción “no-touch-required” a ssh-keygen, que desactiva la necesidad de confirmar físicamente el acceso al token al generar la clave;
- Se agregó una directiva PubkeyAuthOptions a sshd_config, que combina varias opciones relacionadas con la autenticación de clave pública. Actualmente, solo se admite el indicador "no se requiere contacto" para omitir las comprobaciones de presencia física para la autenticación de token. Por analogía, se ha agregado la opción “no-touch-required” al archivo autorizado_keys;
- Se agregó la opción "-O write-attestation=/path" a ssh-keygen para permitir que se escriban certificados de atestación FIDO adicionales al generar claves. OpenSSH aún no utiliza estos certificados, pero se pueden utilizar más adelante para verificar que la clave esté guardada en una tienda de hardware confiable;
- En la configuración de ssh y sshd, ahora es posible configurar el modo de priorización del tráfico a través de la directiva IPQoS. (Comportamiento por salto de menor esfuerzo);
- En ssh, al configurar el valor “AddKeysToAgent=yes”, si la clave no contiene un campo de comentario, se agregará a ssh-agent indicando la ruta a la clave como comentario. EN
ssh-keygen y ssh-agent ahora también usan etiquetas PKCS#11 y el nombre del sujeto X.509 en lugar de la ruta de la biblioteca como comentarios en la clave; - Se agregó la capacidad de exportar PEM para claves DSA y ECDSA a ssh-keygen;
- Se agregó un nuevo ejecutable, ssh-sk-helper, utilizado para aislar la biblioteca de acceso al token FIDO/U2F;
- Se agregó la opción de compilación “--with-zlib” a ssh y sshd para compilar con soporte de biblioteca zlib;
- De acuerdo con el requisito de RFC4253, se proporciona una advertencia sobre el bloqueo de acceso por exceder los límites de MaxStartups en el banner que se muestra durante la conexión. Para simplificar el diagnóstico, el encabezado del proceso sshd, visible cuando se usa la utilidad ps, ahora muestra la cantidad de conexiones autenticadas actualmente y el estado del límite de MaxStartups;
- En ssh y ssh-agent, al llamar a un programa para mostrar una invitación en la pantalla, especificada a través de $SSH_ASKPASS, ahora se transmite adicionalmente un indicador con el tipo de invitación: "confirmar" - diálogo de confirmación (sí/no), "ninguno" " - mensaje informativo, "en blanco" - solicitud de contraseña;
- Se agregó una nueva operación de firmas digitales "find-principals" a ssh-keygen para buscar en el archivo de firmantes permitidos el usuario asociado con una firma digital específica;
- Soporte mejorado para el aislamiento de procesos sshd en Linux usando el mecanismo seccomp: deshabilitando las llamadas al sistema IPC, permitiendo clock_gettime64(), clock_nanosleep_time64 y clock_nanosleep().
Fuente: opennet.ru