Una clave SSH es una credencial de acceso en el protocolo SSH. Su función es similar a la de los nombres de usuario y las contraseñas, pero las claves se utilizan principalmente para los procesos automatizados y para implementar el inicio de sesión único por parte de los administradores de sistemas y los usuarios avanzados.
Las claves SSH son credenciales de autenticación
SSH (Secure Shell) se utiliza para gestionar redes, sistemas operativos y configuraciones. También está dentro de muchas herramientas de transferencia de archivos y de gestión de la configuración. Todas las grandes corporaciones lo utilizan, en todos los centros de datos.
Las claves SSH permiten la automatización que hace posible y rentable los modernos servicios en la nube y otros servicios dependientes de la informática. Ofrecen comodidad y mayor seguridad cuando se gestionan adecuadamente.
Funcionalmente las claves SSH se asemejan a las contraseñas. Conceden acceso y controlan quién puede acceder a qué. En la gestión de la identidad y el acceso, necesitan políticas, aprovisionamiento y terminación similares a las de las cuentas de usuario y las contraseñas. No se puede tener confidencialidad, integridad o cualquier garantía de disponibilidad continua de los sistemas sin controlar las claves SSH.
Técnicamente las claves son claves criptográficas que utilizan un criptosistema de clave pública. Sin embargo, funcionalmente son credenciales de autenticación y necesitan ser gestionadas como tales.
Las claves autorizadas definen quién puede acceder a cada sistema
Las claves autorizadas son claves públicas que conceden acceso. Son análogas a las cerraduras que la llave privada correspondiente puede abrir.
Para obtener más información, consulte la página dedicada a las llaves autorizadas.
Las llaves de identidad identifican a los usuarios y proporcionan acceso
Las llaves de identidad son llaves privadas que un cliente SSH utiliza para autenticarse al iniciar sesión en un servidor SSH. Son análogas a las llaves físicas que pueden abrir una o más cerraduras.
Las llaves autorizadas y las llaves de identidad se denominan conjuntamente llaves de usuario. Están relacionadas con la autenticación de usuario, a diferencia de las claves de host que se utilizan para la autenticación de host.
Para obtener más información, consulte la página dedicada a las claves de identidad.
Autenticación de usuario basada en certificados
Los certificados PKI también se pueden utilizar para la autenticación. En este caso, el usuario sigue teniendo una clave privada pero también tiene un certificado asociado a la clave. Esta tecnología está soportada tanto en Tectia SSH como en OpenSSH, con algunas diferencias. Para más información, consulte la página dedicada a la autenticación basada en certificados en SSH.
Claves de autenticación de dispositivos
Las claves de host autentican servidores
Las claves de host se utilizan para autenticar hosts, es decir, ordenadores. Su objetivo es evitar los ataques de tipo man-in-the-middle. Consulte la página separada sobre claves de host para obtener más información.
La autenticación de host basada en certificados puede ser una alternativa muy atractiva en las grandes organizaciones. Permite que las claves de autenticación de los dispositivos sean rotadas y gestionadas convenientemente y que cada conexión esté asegurada.
Claves de host conocidas
Una de las características únicas de SSH es que, por defecto, confía y recuerda la clave del host cuando se conecta a él por primera vez. Este fue un diferenciador clave que permitió que SSH se desplegara de forma popular, ya que no había una infraestructura de claves centralizada para los hosts en 1995, y todavía no lo es hoy (2017), con la excepción de los certificados SSL para los servidores web. La facilidad de despliegue resultante fue una de las principales razones por las que SSH se convirtió en un éxito.
Las claves de host memorizadas se llaman claves de host conocidas y se almacenan en un archivo llamado known_hosts
en OpenSSH. Mientras las claves de host no cambien, este enfoque es muy fácil de usar y proporciona una seguridad bastante buena. Sin embargo, en organizaciones grandes y cuando las claves cambian, el mantenimiento de los archivos de hosts conocidos puede llegar a consumir mucho tiempo. En ese caso, se recomienda utilizar certificados para las claves de host. Tectia SSH admite certificados X.509 estándar para los hosts. OpenSSH tiene su propio formato de certificado propietario. La ventaja de los certificados basados en el estándar es que pueden ser emitidos por cualquier autoridad de certificación (CA), mientras que no existen CAs fiables para las claves de OpenSSH. Consulte la página dedicada a los certificados con SSH para obtener más información.
Claves de sesión
Una clave de sesión en SSH es una clave de cifrado utilizada para cifrar la mayor parte de los datos en una conexión. La clave de sesión se negocia durante la conexión y luego se utiliza con un algoritmo de cifrado simétrico y un algoritmo de código de autenticación de mensajes para proteger los datos. Para más información, vea la página separada sobre claves de sesión.
Cómo configurar la autenticación basada en claves
La autenticación basada en claves en SSH se llama autenticación de clave pública. Es fácil de configurar por los usuarios finales en la configuración por defecto. Por otro lado, las organizaciones preocupadas por la seguridad necesitan establecer políticas claras para el aprovisionamiento y la terminación del acceso basado en claves.
Cómo configurar la autenticación de clave pública para OpenSSH
Las claves SSH se configuran normalmente en un archivo authorized_keys en .ssh
subdirectorio en el directorio de inicio del usuario. Normalmente, un administrador del sistema crearía primero una clave utilizando ssh-keygen
y luego la instalaría como una clave autorizada en un servidor utilizando la herramienta ssh-copy-id
. Consulte también la página dedicada a la configuración de claves autorizadas para OpenSSH.
Recomendamos utilizar frases de paso para todas las claves de identidad utilizadas para el acceso interactivo. En principio, recomendamos utilizar frases de contraseña para el acceso automatizado también, pero esto a menudo no es práctico.
Almacenamiento de claves en ssh-agent para el inicio de sesión único
SSH viene con un programa llamado ssh-agent
, que puede mantener las claves privadas descifradas del usuario en la memoria y utilizarlas para autenticar los inicios de sesión. El agente también puede utilizarse para acceder a las claves en una tarjeta inteligente o en un módulo de seguridad de hardware (HSM). Consulte la documentación de ssh-agent para saber cómo configurarlo.
La conexión al agente SSH puede reenviarse a un servidor, de modo que el inicio de sesión único también funciona a partir de ese servidor. Esa característica debe usarse con cuidado, ya que permite que un servidor comprometido utilice las credenciales del usuario del agente original. Sin embargo, el reenvío de agentes puede ser una característica muy conveniente para los usuarios avanzados en entornos menos críticos para la seguridad.
Para habilitar el reenvío de agentes, establece AllowAgentForwarding
a yes
en /etc/ssh/sshd_config en el servidor y ForwardAgent
a yes
en el archivo de configuración del cliente /etc/ssh/ssh_config.
Tamaños de clave recomendados
Recomendamos seleccionar los tamaños de clave según NIST SP 800-57. Los tamaños de clave por defecto utilizados por la herramienta ssh-keygen
suelen tener una fuerza aceptable. De hecho, dado que el protocolo nunca revela las claves públicas aceptables para la autenticación del usuario, los algoritmos utilizados para las claves no son tan críticos como lo son en, por ejemplo, los certificados PKI.
Para las claves RSA, 2048 bits es probablemente una buena elección hoy en día (2017). Sin embargo, muchos criptógrafos recomiendan ahora cambiar a claves ECDSA y piensan que los avances en la factorización de enteros grandes pueden hacer que las claves RSA sean vulnerables a corto/medio plazo. Para ECDSA recomendamos utilizar claves de 521 bits (¡sic!), aunque probablemente sean seguras las de 384 o incluso 256 bits. Simplemente no hay ningún beneficio práctico de usar claves más pequeñas.
Localización de la clave de identidad
Las claves de identidad se almacenan normalmente en el directorio de un usuario .ssh
, por ejemplo, .ssh/ssh_id_rsa
. El nombre de archivo de la clave de identidad por defecto comienza con id_<algorithm>
. Sin embargo, es posible especificar cualquier nombre de archivo y cualquier ubicación al crear una clave privada, y proporcionar el nombre de la ruta con la opción -i
al cliente SSH. Por ejemplo, ssh -i /home/ylo/secure/my-key [email protected]
utilizaría una clave privada del archivo my-key
para la autenticación.
La ubicación de la clave de identidad por defecto también se puede configurar en /etc/ssh/ssh_config o en el archivo .ssh/config
del usuario utilizando la opción IdentityFile
.
Localización de las claves autorizadas
Cuando un usuario intenta iniciar sesión utilizando la autenticación basada en claves, el servidor OpenSSH busca las claves autorizadas en un directorio especificado en la configuración del servidor utilizando la opción AuthorizedKeysFile
. El valor por defecto es .ssh/authorized_keys
en el directorio personal del usuario.
Sin embargo, tener las claves autorizadas almacenadas en el directorio personal del usuario significa que éste puede añadir nuevas claves que autoricen los inicios de sesión en su cuenta. Esto es conveniente, pero el usuario puede entonces dar estas claves a amigos o colegas, o incluso venderlas por Bitcoins (esto ha sucedido realmente). Las claves SSH son, además, permanentes y siguen siendo válidas hasta que se eliminan expresamente.
Si se añaden claves autorizadas para las cuentas de root o de servicio, es fácil que sigan siendo válidas incluso después de que la persona que las instaló haya dejado la organización. También son una forma conveniente para que los hackers establezcan una presencia permanente en un sistema si no hay detección y alertas sobre las nuevas claves no autorizadas.
Por estas razones, la mayoría de las organizaciones más grandes quieren mover las claves autorizadas a una ubicación propiedad de la raíz y establecieron un proceso de aprovisionamiento y terminación controlado para ellas.
Mover las claves SSH a una ubicación propiedad de la raíz
En principio, mover las claves SSH a una ubicación propiedad de la raíz es fácil:
-
Crear un directorio adecuado propiedad de la raíz, por ejemplo,
/etc/ssh/keys
, bajo el cual se almacenan las claves autorizadas. -
Cree un subdirectorio bajo este directorio para cada usuario, y mueva el archivo
authorized_keys
de cada usuario a/etc/ssh/keys/<user>/authorized_keys
. -
Por último, cambia el conjunto
AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys
en/etc/ssh/sshd_config
.
En la práctica, sin embargo, esto no siempre es tan sencillo, sobre todo en entornos grandes. Los nombres de usuario pueden proceder de directorios (por ejemplo, Active Directory o LDAP). Muchas organizaciones tienen diferentes versiones de OpenSSH, incluyendo sistemas muy antiguos o construcciones SSH personalizadas que tienen rutas incorporadas no estándar. Recomendamos el uso de herramientas de gestión de claves como Universal SSH Key Manager para ocultar esta complejidad en los entornos más grandes. Estas herramientas también pueden implementar un flujo de trabajo de aprovisionamiento, terminación y aprobación de claves y alertas sobre cambios no autorizados realizados por usuarios root.
Limitación de OpenSSH en el número de claves privadas
El servidor OpenSSH tiene una característica (yo lo llamaría un bug) que cuenta la prueba de si una clave particular puede ser utilizada para la autenticación como un intento de autenticación. Esto tiene como consecuencia que si el usuario tiene más de cinco claves en .ssh
, sólo algunas de ellas funcionan. Esto a menudo hace que la autenticación basada en claves falle y suele ser difícil de entender para los usuarios. La forma de evitarlo es especificar explícitamente la clave privada que se va a utilizar utilizando la opción -i
. Una alternativa es ajustar la sesión de MaxAuthTries
en el servidor, pero esto no es una solución completa y no es conveniente aumentar el número de intentos de autenticación de la contraseña.
Cómo son las claves SSH
Una clave autorizada puede tener este aspecto:
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN+Mh3U/3We4VYtV1QmWUFIzFLTUeegl1Ao5/QGtCRGAZn8bxX9KlCrrWISIjSYAwCajIEGSPEZwPNMBoK8XD8Q= ylo@klar
Una clave de identidad puede tener este aspecto:
-----BEGIN EC PRIVATE KEY-----MHcCAQEEIJWbvSW7h50HPwG+bWR3DXgQ6YhOxYbe0ifr1rRUvsUuoAoGCCqGSM49AwEHoUQDQgAE34yHdT/dZ7hVi1XVCZZQUjMUtNR56CXUCjn9Aa0JEYBmfxvFf0qUKutYhIiNJgDAJqMgQZI8RnA80wGgrxcPxA==-----END EC PRIVATE KEY-----
¿Cómo funciona la autenticación en SSH?
Iniciar una conexión en SSH consiste en:
-
Negociar la versión del protocolo a utilizar
-
Negociar los algoritmos criptográficos y otras opciones a utilizar
-
Negociar unavez para cifrar el resto de la sesión
-
Autenticar el host del servidor utilizando su clave de host
-
Autenticar al usuario utilizando una contraseña autenticación de clave pública, u otros medios.
Después de esto, se pueden intercambiar datos, incluyendo datos de terminal, gráficos y archivos.
Autenticación de clave pública
El mecanismo de autenticación basado en claves en SSH se llama autenticación de clave pública. Esencialmente, algunos datos específicos de la sesión se firman utilizando la clave de identidad privada. La firma se envía entonces al servidor que comprueba si la clave utilizada para la firma está configurada como una clave autorizada. A continuación, el servidor verifica la firma digital utilizando la clave pública de la clave autorizada. La clave de identidad nunca se envía al servidor.
Lo esencial en la autenticación de clave pública es que permite que un servidor acceda a otro sin tener que teclear una contraseña. Esta poderosa característica es la razón por la que se utiliza tanto para la transferencia de archivos (mediante el protocolo SFTP) y la gestión de la configuración. También es comúnmente utilizado por los administradores de sistemas para el inicio de sesión único.
Qué tan comunes son las claves SSH y cuál es el riesgo
Las claves SSH resultan ser extremadamente comunes y ampliamente utilizadas. Muchas grandes organizaciones las han acumulado durante veinte años sin ningún tipo de control. Una empresa típica de la lista Fortune 500 tiene varios millones de claves que dan acceso a sus servidores. En el caso de un cliente, examinamos 500 aplicaciones y 15.000 servidores, y encontramos 3.000.000 de claves autorizadas y 750.000 pares de claves únicas. Esta organización también tenía más de cinco millones de inicios de sesión diarios utilizando claves. Las claves se utilizaban para ejecutar transacciones financieras, actualizar configuraciones, mover datos de registro, transferencias de archivos, inicios de sesión interactivos por parte de los administradores de sistemas y muchos otros fines.
Resulta que la mayoría de las grandes empresas tienen cientos de miles o incluso millones de claves. Estas claves son accesos que no se contabilizan y que pueden poner en riesgo a toda la empresa.
Cómo eliminar por completo las claves SSH
El gestor de acceso bajo demanda PrivX puede utilizarse para eliminar por completo las claves SSH de los servidores y establecer un control de acceso y un registro de sesiones basados en políticas en toda la empresa. También elimina la mayor parte de la carga administrativa en la gestión de claves, sin dejar de ofrecer las ventajas: automatización e inicio de sesión único.