{"id":42941,"date":"2020-02-17T14:41:56","date_gmt":"2020-02-17T11:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f"},"modified":"2020-02-17T14:41:56","modified_gmt":"2020-02-17T11:41:56","slug":"reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","title":{"rendered":"Lanzamiento de OpenSSH 8.2 con soporte para tokens de autenticaci\u00f3n de dos factores FIDO\/U2F","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Despu\u00e9s de cuatro meses de desarrollo presentado<\/a><\/noindex> lanzamiento OpenSSH 8.2<\/a><\/noindex>, una implementaci\u00f3n abierta de cliente y servidor para trabajar con los protocolos SSH 2.0 y SFTP. <\/p>\n

La mejora clave en la versi\u00f3n OpenSSH 8.2 fue la posibilidad de utilizar la autenticaci\u00f3n de dos factores mediante dispositivos que soportan el protocolo U2F<\/a><\/noindex>, desarrollado por la alianza FIDO<\/a><\/noindex>. U2F permite crear tokens de hardware baratos para confirmar la presencia f\u00edsica del usuario, que interact\u00faan a trav\u00e9s de USB, Bluetooth o NFC. Estos dispositivos se promueven como un medio para la autenticaci\u00f3n 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.<\/p>\n

Para interactuar con dispositivos que confirman la presencia del usuario, OpenSSH ha a\u00f1adido nuevos tipos de claves \u00abecdsa-sk\u00bb y \u00abed25519-sk\u00bb, que utilizan algoritmos de firma digital ECDSA y Ed25519, junto con el hash SHA-256. Los procedimientos de interacci\u00f3n con los tokens se han trasladado a una biblioteca intermedia, que se carga de manera similar a la biblioteca para el soporte de PKCS#11 y act\u00faa como un enlace sobre la biblioteca. libfido2<\/a><\/noindex>, que proporciona medios para la comunicaci\u00f3n con los tokens a trav\u00e9s 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 incluida<\/a><\/noindex> est\u00e1 integrada en libfido2, al igual que el controlador HID<\/a><\/noindex> para OpenBSD.<\/p>\n

Para la autenticaci\u00f3n y generaci\u00f3n de claves, es necesario especificar en la configuraci\u00f3n el par\u00e1metro \u00abSecurityKeyProvider\u00bb o establecer la variable de entorno SSH_SK_PROVIDER, indicando la ruta a la biblioteca externa libsk-libfido2.so (export SSH_SK_PROVIDER=\/ruta\/a\/libsk-libfido2.so). Tambi\u00e9n es posible compilar openssh con soporte integrado para la biblioteca de capa intermedia (\u2014with-security-key-builtin); en este caso, es necesario establecer el par\u00e1metro \u00abSecurityKeyProvider=internal\u00bb.
\nA continuaci\u00f3n, debes ejecutar \u00abssh-keygen -t ecdsa-sk\u00bb o, si las claves ya est\u00e1n creadas y configuradas, conectarte al servidor usando \u00abssh\u00bb. Al ejecutar ssh-keygen, el par de claves creado se guardar\u00e1 en \u00ab~\/.ssh\/id_ecdsa_sk\u00bb y puede ser utilizado de manera similar a otras claves. <\/p>\n

La clave p\u00fablica (id_ecdsa_sk.pub) debe ser copiada al servidor en el archivo authorized_keys. En el lado del servidor, solo se verifica la firma digital, mientras que la interacci\u00f3n con los tokens se realiza del lado del cliente (no es necesario instalar libsk-libfido2 en el servidor, pero el servidor debe admitir el tipo de claves \u00abecdsa-sk\u00bb). La clave privada generada (id_ecdsa_sk) es esencialmente un descriptor de la clave, que forma la clave real solo en combinaci\u00f3n con una secuencia secreta almacenada en el token U2F. En caso de que la clave id_ecdsa_sk caiga en manos de un atacante, para completar la autenticaci\u00f3n tambi\u00e9n necesitar\u00e1 acceder al token de hardware, sin el cual la clave privada almacenada en el archivo id_ecdsa_sk es in\u00fatil. <\/p>\n

Adem\u00e1s, por defecto, al realizar cualquier operaci\u00f3n con claves (tanto al generarlas como al autenticar) se requiere una confirmaci\u00f3n local de la presencia f\u00edsica 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\u00f3n, al iniciar ssh-keygen tambi\u00e9n se puede establecer una contrase\u00f1a para acceder al archivo de clave. <\/p>\n

En la nueva versi\u00f3n de OpenSSH tambi\u00e9n se ha anunciado la pr\u00f3xima desactivaci\u00f3n de los algoritmos que utilizan hashes SHA-1, debido a un aumento<\/a><\/noindex> la efectividad de los ataques de colisi\u00f3n con un prefijo espec\u00edfico (el costo de encontrar una colisi\u00f3n se estima en aproximadamente 45 mil d\u00f3lares). En una de las pr\u00f3ximas versiones, se planea deshabilitar por defecto la posibilidad de usar el algoritmo de firma digital de clave p\u00fablica \u00abssh-rsa\u00bb, el cual se menciona en el RFC original para el protocolo SSH y sigue siendo ampliamente utilizado en la pr\u00e1ctica (para verificar la aplicaci\u00f3n de ssh-rsa en sus sistemas, se puede intentar conectarse por ssh con la opci\u00f3n \u00ab-oHostKeyAlgorithms=-ssh-rsa\u00bb).<\/p>\n

Para suavizar la transici\u00f3n a nuevos algoritmos en OpenSSH, en una de las siguientes versiones se activar\u00e1 por defecto la configuraci\u00f3n UpdateHostKeys, que permitir\u00e1 a los clientes migrar autom\u00e1ticamente a algoritmos m\u00e1s seguros. Entre los algoritmos recomendados para la migraci\u00f3n 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).<\/p>\n

En la versi\u00f3n OpenSSH 8.2, la posibilidad de conectarse utilizando \u00abssh-rsa\u00bb se ha mantenido, pero este algoritmo ha sido eliminado de la lista CASignatureAlgorithms, que especifica 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 observa que el uso de SHA-1 en certificados conlleva un riesgo adicional, ya que un atacante tiene un tiempo ilimitado para encontrar una colisi\u00f3n para un certificado existente, mientras que el tiempo de ataque a las claves de host est\u00e1 limitado por el tiempo de espera de conexi\u00f3n (LoginGraceTime). <\/p>\n

Al ejecutar ssh-keygen, ahora se utiliza por defecto el algoritmo rsa-sha2-512, que se ha soportado desde OpenSSH 7.2, lo que puede crear problemas de compatibilidad al intentar procesar certificados firmados en OpenSSH 8.2 en sistemas con versiones antiguas de OpenSSH (para eludir el problema al generar la firma, se puede especificar expl\u00edcitamente \u00abssh-keygen -t ssh-rsa\u00bb o utilizar los algoritmos ecdsa-sha2-nistp256\/384\/521, soportados desde OpenSSH 5.7).<\/p>\n

Otros cambios:<\/p>\n