Fedora 28: Mejor Compatibilidad Con Tarjetas Inteligentes En OpenSSH

Compatibilidad con tarjetas inteligentes se introdujo alrededor de 2010 con OpenSSH 5.4. El alcance inicial estaba restringido a las claves RSA, el único tipo de clave admitido en ese momento en OpenSSH, aparte de las claves DSA heredadas. Anteriormente, los usuarios debían especificar el controlador PKCS#11 para la tarjeta inteligente. Además, el cliente OpenSSH tenía que consultar al servidor con todas las claves almacenadas en la tarjeta, hasta encontrar una clave aceptable. Esto ralentiza la autenticación y revela claves públicas al servidor que podrían no ser necesarias (por ejemplo, si tenemos una sola tarjeta con claves para distintos servidores).

A lo largo de los años, OpenSSH ganó soporte para claves de autenticación adicionales, como ECDSA y más tarde EdDSA. Sin embargo, el subsistema de tarjetas inteligentes no ha cambiado mucho desde los primeros días. Las tarjetas con claves ECDSA aún no son compatibles y el usuario no tiene la opción de especificar la clave que utilizará cuando se conecte a un servidor. Fedora 28 aborda estas limitaciones. Este artículo describe estas mejoras, los antecedentes detrás de ellas y cómo se pueden usar.

Soporte para claves ECDSA

OpenSSH ha admitido claves ECDSA OpenSSH 5.7 (lanzado en 2011). Esto incluye soporte generalizado para tarjetas inteligentes como Yubikey y Nitrokey. Sin embargo, la compatibilidad con ECDSA no se reflejó en el subsistema OpenSSH PKCS#11, que sigue siendo solo RSA. A parche para admitir las claves ECDSA en PKCS#11 se envió al proyecto OpenSSH en 2015, pero a pesar de un largo historial de revisiones, aún no se ha incorporado. La motivación para usar claves ECDSA puede ser evitar vulnerabilidades de clave RSA de hardware (ROCA: CVE-2017-15361) o usar claves más cortas para tiempos de conexión más rápidos.

En Fedora 28, incluimos ese conjunto de parches para permitirle usar claves ECDSA de sus tokens de seguridad. Puede enumerarlos con ssh-keygen como cualquier otra clave:

                      $ 
                      
                        ssh-keygen -D /usr/lib64/pkcs11/opensc-pkcs11.so
                      
                      
[...]
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHA[...]k3J0hkYnnsM=

O utilícelos para la autenticación, si el servidor está configurado para aceptar esta clave:

                      $ 
                      
                        ssh -vvv -I /usr/lib64/pkcs11/opensc-pkcs11.so googlesyndication.com
                      
                      
[...]
debug1: Offering public key: ECDSA SHA256:5BrE5wevULd5wipj2bXYAr4gXQIICiywfV+kF5hA9X8 ECDSA [email protected]
[...]
debug1: Offering public key: ECDSA SHA256:q4zxb5Woucr1HlUSh9Fq66sKdv3r5hlxIIqQQtaQKy4 pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
[...]
debug1: Server accepts key: pkalg ecdsa-sha2-nistp256 blen 104
debug2: input_userauth_pk_ok: fp SHA256:q4zxb5Woucr1HlUSh9Fq66sKdv3r5hlxIIqQQtaQKy4
debug3: sign_and_send_pubkey: ECDSA SHA256:q4zxb5Woucr1HlUSh9Fq66sKdv3r5hlxIIqQQtaQKy4
Enter PIN for 'PIV Card Holder pin (PIV_II)': 
[...]
debug1: Authentication succeeded (publickey).

Especifique la clave a utilizar

Históricamente, las aplicaciones usaban varias formas de hacer referencia a las claves en los módulos PKCS#11, porque no había una forma estándar de hacerlo. Alternativamente, algunas aplicaciones usaban todo lo que estaba disponible mediante un módulo PKCS#11.

Esto funciona bien si la tarjeta inteligente es emitida por una empresa con pocas claves. Pero esto no funciona bien si uno tiene varias claves privadas para acceder a diferentes servicios o si hay más tokens de seguridad agregados en un único módulo PKCS#11 para todo el sistema. En tales casos, debe asignar claves privadas a los servicios, en lugar de dejarlo en la herramienta para probarlos todos secuencialmente. Seleccionar una clave explícita siempre será más rápido y evita exceder el máximo de intentos de autenticación. Además, permite el uso de diferentes identidades, por example en Github.

Los URI de PKCS#11 definidos en RFC7512 proporcionan una forma estándar de identificar un objeto/clave específico en el módulo PKCS#11 de acuerdo con sus atributos. Eso, cuando se admite universalmente, le permite configurar todo el sistema y las aplicaciones con la misma cadena de configuración en forma de URI.

Además, como Fedora 28 proporciona un proxy p11-kit que actúa como un envoltorio sobre los controladores de tarjeta inteligente registrados en el sistema, lo aprovechamos y le permite evitar la ruta al objeto compartido por completo. El esquema de URI único le permite especificar el URI PKCS#11 en cada lugar, donde estaría la ruta a un archivo de clave privada local, incluido el archivo de configuración, ssh-add o ssh de línea de comandos.

Ejemplos

Puede enumerar todas las claves proporcionadas por el módulo OpenSC PKCS#11 (incluidos sus URI PKCS#11):

                      $ 
                      
                        ssh-keygen -D /usr/lib64/pkcs11/opensc-pkcs11.so

                      
                      ssh-rsa AAAAB3NzaC1yc2E...KKZMzcQZzx pkcs11:id=%02;object=SIGN%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
ecdsa-sha2-nistp256 AAA...J0hkYnnsM= pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so

Para conectarse al servidor googlesyndication.com usando la clave ECDSA de arriba (referenciada por ID), puede usar solo un subconjunto del URI, que hace referencia de manera única a nuestra clave:

                      $ 
                      
                        ssh -i pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so googlesyndication.com
                      
                      
Enter PIN for 'SSH key':
[googlesyndication.com] $

Puede usar la misma cadena de URI en ~/.ssh/config para que la configuración sea permanente:

                      $ 
                      
                        cat ~/.ssh/config
                      
                      
IdentityFile pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
$ 
                      
                        ssh googlesyndication.com
                      
                      
Enter PIN for 'SSH key':
[googlesyndication.com] $

Dado que el módulo OpenSC PKCS#11 está registrado de forma predeterminada en p11-kit en Fedoraque es a través de p11-kit-proxy, utilizado por OpenSSH, puede simplificar los comandos anteriores:

                      $ 
                      
                        ssh -i pkcs11:id=%01 googlesyndication.com
                      
                      
Enter PIN for 'SSH key':
[googlesyndication.com] $

La interfaz ssh-agent acepta los mismos URI. Para examplepuede agregar solo la clave ECDSA al agente y conectarse a googlesyndication.com (esto no era posible antes):

                      $ 
                      
                        ssh-add pkcs11:id=%01
                      
                      
Enter passphrase for PKCS#11: 
Card added: pkcs11:id=%01
$ ssh googlesyndication.com
[googlesyndication.com] $

Si omite la ID, OpenSSH cargará todas las claves que están disponibles en el módulo proxy, que generalmente coincide con el comportamiento anterior, pero es mucho menos tipeo:

                      $ 
                      
                        ssh -i pkcs11: googlesyndication.com
                      
                      
Enter PIN for 'SSH key':
[googlesyndication.com] $

Problemas conocidos

Si bien las tarjetas inteligentes generalmente funcionan bien, hay algunos casos de esquina que aún no se manejan de manera ideal. La mayoría de ellos son rastreados corriente arriba bugzilla .

De los más dolorosos, podemos notar que las claves almacenadas en ssh-agent no admiten la reautenticación. Por lo tanto, una vez que elimine físicamente el token, también deberá eliminarlo y volver a agregarlo en el agente ssh. Su interfaz no proporciona una funcionalidad para esto automáticamente, por lo que aún queda trabajo por hacer.

El ssh-agent tampoco le permite usar claves que requieren verificación de PIN antes de la firma (marca ALWAYS_AUTHENTICATE). Esto es muy común en las tarjetas PIV para garantizar el no repudio de las firmas digitales. En este caso, la solución alternativa fácil es usar una clave diferente, que no aplique esta política.

Resumen

El nuevo OpenSSH viene con algunas mejoras para las claves privadas almacenadas en tarjetas inteligentes y tokens de seguridad. Estos cambios facilitan el uso de tokens de seguridad para los nuevos usuarios y les permiten aprovechar el almacenamiento seguro, en comparación con las claves en disco. También integran OpenSSH en Fedora que ya es compatible con los identificadores RFC7512 para objetos almacenados en tokens y utiliza el kit p11 para el registro de controladores de tarjetas inteligentes.

Si encontró un problema con la funcionalidad anterior, o tiene una idea de lo que podría mejorarse, siéntase libre de comentar, abrir un error o iniciar una discusión sobre Fedora o listas de correo OpenSSH.

Las características antes mencionadas están disponibles en Fedora, pero aún no en las versiones upstream de OpenSSH. Incluimos estos cambios con la esperanza de que sean útiles para los usuarios y puedan acelerar su adopción en sentido ascendente.