Gestión de claves para OpenSSH, Parte 11. Entendiendo la autenticación RSA/DSA Muchos de nosotros usamos el excelente OpenSSH (vea Recursos, más adelante en este artículo) como un reemplazo seguro y encriptado de los vulnerables telnet y rsh. Una de las características más intrigantes de OpenSSH es su capacidad para autenticar usuarios usando los protocolos RSA y DSA de autenticación, basados en un par de claves numéricas complementarias. Como uno de sus principales atractivos, las autenticaciones RSA y DSA prometen la habilidad de establecer conexiones con sistemas remotos sin proporcionar una contraseña. A pesar de que esto es interesante, los nuevos usuarios de OpenSSH muchas veces configuran RSA/DSA de forma rápida y sucia, dando como resultado una entrada en el sistema sin necesidad de contraseña, pero dejando abierto un gran agujero de seguridad en el proceso. ¿Qué es la autenticación RSA/DSA? SSH, en especial OpenSSH (una implementación completamente libre de SSH), es una herramienta increíble. Como telnet o rsh, el cliente ssh puede ser usado para iniciar sesión en una máquina remota. Todo lo que se necesita es que la máquina remota esté ejecutando sshd, el proceso del servidor ssh. Sin embargo, a diferencia de telnet, el protocolo ssh es muy seguro. Usa algoritmos especiales para encriptar el flujo de datos, asegurando la integridad del canal de datos e incluso llevando a cabo autenticación de una forma segura y protegida. Sin embargo, aunque que ssh es realmente magnífico, hay una cierto componente de la funcionalidad de ssh que la mayor parte de las veces se ignora, no se conoce o, simplemente, se entiende mal. Este componente es el sistema de autenticación mediante clave RSA/DSA, una alternativa al sistema de autenticación estándar de contraseña segura que OpenSSH usa por defecto. Los protocolos de autenticación RSA y DSA de OpenSSH están basados en un par de claves criptográficas especialmente creadas, denominadas clave privada y clave pública. La ventaja de usar este sistema de autenticación basado en claves es que, en muchos casos, es posible establecer una conexión segura sin tener que escribir una contraseña a mano. Mientras que los protocolos de autenticación basados en claves son relativamente seguros, los problemas surgen cuando los usuarios se toman algunos atajos por comodidad, sin entender completamente sus implicaciones en materia de seguridad. En este artículo echaremos un buen vistazo a cómo usar correctamente los protocolos de autenticación RSA y DSA sin exponernos nosotros mismos a cualquier riesgo de seguridad innecesario. En mi siguiente artículo, le enseñaré cómo usar ssh-agent para guardar claves privadas desencriptadas, e introduciremos keychain, un interfaz de ssh-agent que ofrece un buen número de cómodas ventajas sin sacrificar la seguridad. Si siempre ha querido cogerle el truco a las características de autenticación avanzadas de OpenSSH, entonces siga leyendo. Cómo funcionan las claves RSA/DSA He aquí un rápido vistazo general de cómo funcionan las claves RSA/DSA. Vamos a empezar con un hipotético escenario donde nos gustaría usar la autenticación RSA para permitir que una estación de trabajo Linux local (llamada localbox) abra un shell remoto en remotebox, una máquina en nuestro ISP. En este momento, cuando intentemos conectarnos a remotebox usando el cliente ssh, obtendríamos el siguiente prompt:
Aquí vemos un ejemplo de la forma por defecto de ssh de llevar a cabo la autenticación. A saber, pregunta por la contraseña de la cuenta de drobbins en remotebox. Si introducimos nuestra contraseña para remotebox, ssh usa su protocolo seguro de autenticación por contraseña, transmitiendo nuestra contraseña a remotebox para su verificación. Sin embargo, al contrario de lo que hace telnet, aquí nuestra contraseña está encriptada para que no pueda ser interceptada por nadie que esté escuchando nuestra conexión. Una vez que remotebox autentica la contraseña que hemos dado con su base de datos de contraseñas, si es correcta, tendremos acceso y seremos recibidos con un intérprete de comandos de remotebox. Mientras que el método por defecto de autenticación de ssh es bastante seguro, la autenticación RSA y DSA abre algunas nuevas posibilidades. Sin embargo, al contrario que la autenticación de contraseña segura de ssh, la autenticación RSA requiere alguna configuración inicial. Necesitamos hacer estos pasos de configuración inicial sólo una vez. Después de eso, la autenticación RSA entre localbox y remotebox será totalmente indolora. Para preparar la autenticación RSA, primero necesitamos generar un par de claves, una privada y una pública. Estas dos claves tienen algunas propiedades muy interesantes. La clave pública puede ser usada para encriptar un mensaje, y sólo el poseedor de la clave privada puede desencriptarlo. La clave pública sólo puede ser usada para encriptación, y la clave privada sólo puede puede ser usada para desencriptación de un mensaje codificado por la clave pública correspondiente. El protocolo de autenticación RSA (y DSA) usan las propiedades especiales de los pares de claves para llevar a cabo autenticación segura, sin necesidad de transmitir ninguna información confidencial por la red. Para hacer que funcione la autenticación RSA o DSA, haremos sólo un único paso de configuración. Copiaremos nuestra clave pública a remotebox. La clave pública se llama "pública" por una razón. Ya que sólo puede ser usada para encriptar mensajes para nosotros, no necesitamos estar demasiado preocupados por si cae en malas manos. Una vez que nuestra clave pública ha sido copiada a remotebox y colocada en un fichero especial (~/.ssh/authorized_keys) para que sshd en remotebox pueda localizarla, estaremos listos para usar la autenticación RSA para entrar en remotebox. Para hacer esto, simplemente escribimos ssh drobbins@remotebox en la consola de localbox, como siempre hacemos. Sin embargo, esta vez, ssh le hará saber al sshd en remotebox que le gustaría usar el protocolo de autenticación RSA. Lo que pasa a continuación es bastante interesante. Sshd en remotebox genera un número aleatorio, y lo encripta usando nuestra clave pública que copiamos ahí anteriormente. Entonces, manda este número aleatorio encriptado de vuelta al ssh que se ejecuta en localbox. A continuación, nuestro ssh usa nuestra clave privada para desencriptar este número aleatorio, y entonces lo envía de vuelta a remotebox, como diciendo "¡Mira, yo realmente tenía la clave privada correspondiente; he sido capaz de desencriptar correctamente tu mensaje!" Finalmente, sshd concluye que deberíamos estar permitidos para entrar, ya que teníamos la clave privada correspondiente. De esta forma, el hecho de que tengamos una clave privada pareja nos garantiza acceder a remotebox. Hay dos observaciones importantes sobre la autenticación RSA y DSA. La primera es que realmente sólo necesitamos generar un par de claves. Podemos entonces copiar nuestra clave pública a las máquinas remotas en las que nos gustaría acceder y todas ellas nos autenticarán felizmente contra nuestra única clave privada. En otras palabras, no necesitamos un par de claves para cada sistema al que nos gustaría tener acceso. Sólo un par es suficiente. La otra observación es que nuestra clave privada no debería caer en malas manos. La clave privada es lo único que nos concede acceso a nuestros sistemas remotos, y cualquiera que posea nuestra clave privada es admitido exactamente con los mismos privilegios que tenemos. Así como no querríamos que personas extrañas tuvieran las llaves de nuestra casa, debemos proteger nuestra clave privada de un uso no autorizado. En el mundo de los bits y los bytes, esto significa que nadie debería poder leer o copiar nuestra clave privada. Desde luego, los desarrolladores de ssh son concientes de la importancia de la claves privadas, y han construído unas pocas salvaguardas en ssh y en ssh-keygen para que nuestra clave privada no sea maltratada. Primero, ssh está configurado para imprimir un gran mensaje de advertencia si nuestra clave tiene permisos de fichero que permitiría ser leída por cualquiera además de nosotros. Segundo, cuando creamos nuestro par de claves pública/privada usando ssh-keygen, ssh-keygen nos pedirá que introduzcamos una frase de paso. Si lo hacemos, nuestra clave privada estará encriptada usando esta frase de paso, así que si incluso fuera robada, será inútil para cualquiera que por casualidad no supiera la frase de paso. Armados con este conocimiento, vamos a echar un vistazo a cómo configurar ssh para usar los protocolos de autenticación RSA y DSA. El primer paso en preparar la autenticación RSA empieza generando un par de claves pública/privada. La autenticación RSA es la forma original de autenticación de claves de ssh, por lo que RSA debería funcionar con cualquier versión de OpenSSH, aunque recomiendo que instales la versión más reciente disponible, que es openssh-2.9_p2 en el momento en el que este artículo fue escrito. Generar un par de claves RSA es como sigue:
Cuando ssh-keygen pregunte por una localización por omisión para la clave, presionamos "Enter" para aceptar la de por defecto de /home/drobbins/.ssh/identity. ssh-keygen guardará la clave privada en la ruta de arriba, y la clave pública estará guardada con ella, en un fichero llamando identity.pub. Hay que notar que ssh-keygen nos preguntó para introducir una frase de paso. Cuando nos preguntó, introducimos una buena frase de paso (siete o más caracteres difíciles de predecir). ssh-keygen entonces encriptó nuestra clave privada (~/.ssh/identity) usando esta frase de paso para que así nuestra clave privada sea inútil para cualquiera que no la conozca. Cuando especificamos una frase de paso, ésta permite a ssh-keygen asegurar nuestra clave privada contra un mal uso, pero también creo un pequeño inconveniente. Ahora, cada vez que intentemos conectar con nuestra cuenta en drobbins@remotebox usando ssh, ssh nos preguntará que introduzcamos la frase de paso para que pueda desencriptar nuestra clave privada y usarla para la autenticación RSA. De nuevo, no estaremos introduciendo nuestra contraseña para la cuenta drobbins en remotebox, estaremos introduciendo la frase de paso necesaria para desencriptar localmente nuestra clave privada. Una vez que nuestra clave privada es desencriptada, nuestro cliente ssh se hará cargo del resto. A pesar de que los mecanismos de usar nuestra contraseña remota y la frase de paso de RSA son completamente diferentes, en la práctica todavía estamos siendo preguntados por una "frase secreta" para escribir en ssh
Aquí es cuando a menudo el usuario se ve abocado a un rápido compromiso. En muchas ocasiones el usuario creará claves privadas sin encriptar para no tener que teclear una contraseña. De esta forma, simplemente se teclea el comando ssh e inmediatamente se produce la autenticación vía RSA (o DSA) y la entrada al sistema.
Sin embargo, a pesar de que esto es un inconveniente, no deberías usar este método sin entender completamente su impacto en seguridad. Con una clave privada desencriptada, si alguien alguna vez trastea en localbox, obtendrán también acceso automático a remotebox y cualquier otros sistemas que hayan sido configurados con la clave pública. Sé lo que está pensando. La autenticación sin contraseña, a pesar de ser un poco arriesgada parece realmente atractiva. Estoy totalmente de acuerdo. ¡Pero hay una manera mejor! Quédese conmigo, y le mostraré cómo obtener los beneficios de la autenticación sin contraseña sin comprometer la seguridad de su clave privada. Le mostraré cómo usar con dominio ssh-agent (lo que hace posible la autenticación sin contraseña segura en primer lugar) en mi siguiente artículo. Ahora, vamos a estar listos para usar ssh-agent preparando la autenticación RSA y DSA. Aquí están las indicaciones paso a paso. Generación del par de claves RSA Para preparar la autenticación RSA, vamos a hacer el único paso de la generación del par de claves pública/privada. Hacemos esto escribiendo:
Acepte la localización por omisión de la clave cuando se le requiera (normalmente ~/.ssh/identity y ~/.ssh/identity.pub para la clave pública), y proporcione a ssh-keygen una frase de paso segura. Una vez termine ssh-keygen, tendrá una clave pública así como una clave privada encriptada con la frase de paso. Instalación de la clave pública RSA A continuación, necesitaremos configurar los sistemas remotos que ejecutan sshd para que usen nuestra clave RSA pública para autenticación. Normalmente, esto se hace copiando la clave pública al sistema local como sigue:
Ya que la autenticación RSA no está completamente preparada aún, seremos preguntados por nuestra contraseña en remotebox. Hágalo. Entonces, inicie sesión en remotebox y añada la clave pública al fichero ~/.ssh/authorized_keys así:
Ahora, con la autenticación RSA configurada, deberíamos ser preguntados por nuestra frase de paso RSA (en vez de nuestra contraseña) cuando intentemos conectarnos a remotebox usando ssh.
¡Enhorabuena, completada la configuración de la autenticación RSA! Si no fuera preguntado por una frase de paso, aquí hay algunas cosas que probar. Primero, intente iniciar sesión escribiendo ssh -1 drobbins@remotebox. Esto le dirá a ssh que use sólo la versión 1 del protocolo ssh, y puede ser necesario si por alguna razón el sistema remoto está usando la autenticación DSA por defecto. Si eso no funciona, asegúrese que no tenga una línea que ponga RSAAuthentication no en su /etc/ssh/ssh_config. Si la tiene, coméntela precediéndola con un "#". En otro caso, intente contactar con el administrador del sistema remotebox y verifique que tienen habilitada la autenticación RSA y tienen las configuraciones apropiadas en /etc/ssh/sshd_config. Mientras que las claves RSA son usadas por la versión 1 del protocolo ssh, las claves DSA son usadas por el protocolo de nivel 2, una versión actualizada del protocolo ssh. Cualquier versión moderna de OpenSSH debería ser capaz de usar ambas claves RSA y DSA. Generar claves DSA usando ssh-keygen de OpenSSH puede hacerse de manera similiar a RSA de la siguiente manera:
De nuevo, seremos preguntados por una frase de paso. Introduzca una segura. También se nos preguntará por una localización para guardar nuestras claves DSA. Las de por defecto, normalmente ~/.ssh/id_dsa y ~/.ssh/id_dsa.pub, deberían estar bien. Después de que nuestra generación única de clave DSA esté completa, es hora de instalar nuestra clave pública DSA en los sistemas remotos. Instalación de la clave pública DSA De nuevo, la instalación de la clave pública DSA es casi idéntica a la RSA. Para DSA, querremos copiar nuestro fichero ~/.ssh/id_dsa.pub a remotebox, y entonces añadirlo a ~/.ssh/authorized_keys2 en remotebox. Note que este fichero tiene un nombre distinto que el fichero authorized_keys de RSA. Una vez configurado, deberíamos ser capaces de iniciar sesión en remotebox escribiendo nuestra frase de paso de la clave privada DSA en vez de escribir nuestra contraseña de remotebox.
Ahora mismo, debería tener la autenticación RSA o DSA funcionando, pero aún necesita escribir su frase de paso en cada nueva conexión. En mi próximo artículo, veremos cómo usar ssh-agent, un sistema realmente bueno que nos permite establecer conexiones sin dar una contraseña, pero también nos permite mantener nuestras claves privadas encriptadas en el disco. También presentaré keychain, un interfaz muy útil de ssh-agent que hace a ssh-agent aún más seguro, práctico y divertido de usar. Hasta entonces, eche un vistazo a los prácticos recursos de abajo para seguir por el buen camino.
|
|