Criptografía pública utilizando SSH
OpenSSH dispone de varios métodos para verificar la identidad de un usuario remoto, uno de ellos es el uso de contraseñas de usuarios, pero otro de los métodos se basa en la autenticación RSA, en donde se dispone de un juego de llaves privada/pública que garantiza la identidad de un usuario intentando conectarse al equipo remoto. El juego de llaves tiene la propiedad de que lo que se encripta con una, sólo se puede desencriptar con la otra, pero sin embargo, a partir de la llave pública no se puede derivar la llave privada.
Para asegurarse de que un usuario es quien dice ser por medio de criptografía pública OpenSSH emplea el siguiente procedimiento: Primero, el servidor genera un número aleatorio que encripta con la llave pública del usuario y le envia el resultado al cliente, si el usuario es quien dice ser entonces no tendrá ningún problema en desencriptarlo. El cliente aplicará una transformación predefinida a dicho número y lo enviará de vuelta al servidor, el cual, revisará dicho resultado y de ser correcto, dará acceso al cliente.
Configurar el servidor para que acepte llaves públicas.
Lo primero que tendremos que hacer será configurar el servidor de SSH para que las acepte. Los archivos de configuración de OpenSSH se ubican en la carpeta /etc/ssh, el archivo que nos interesa es /etc/ssh/sshd_config, lo abrimos con un editor de textos y corregimos para que queden de la siguiente forma:
#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
RSAAuthentication: sirve para indicar cuando se permitirá autenticación RSA, está opción esta habilitada por defecto, y en el ejemplo está comentada porque sólo sirve para la versión 1 del protocolo SSH.
PubkeyAuthentication: es la que especifica si se podrán usar llaves públicas para demostrar la autenticidad de un usuario. Si su valor es yes como en el ejemplo, entonces se podrán emplear las llaves públicas, si por el contrario su valor es no, entonces el uso de llaves públicas quedará prohibido.
AuthorizedKeysFile: especifica el archivo que contiene las llaves públicas empleadas para la autenticación de los usuarios. Por defecto suele ser el archivo .ssh/autorized_keys, dentro de la carpeta personal de cada usuario.
Finalmente, en caso de haber alterado el archivo de configuración del servidor, para que los cambios sean efectivos, será necesario reiniciar el servidor de SSH.
Crear nuevas llaves
Se pueden generar llaves RSA o DSA para el protocolo SSH versión 2. Para especificar que tipo de llave crear, se emplea el parámetro -t seguido del tipo de llave: "rsa" o "dsa". Por ejemplo, para crear una llave RSA podemos poner:
[hell@local] $ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/hell/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/hell/.ssh/id_rsa.
Your public key has been saved in /home/hell/.ssh/id_rsa.pub.
The key fingerprint is:
c0:40:50:27:e8: d9:b8:55: d6:a4:5f:af:e5:30:5d:9b hell@local
[hell@local] $
Por el contrario, para generar una llave DSA, simplemente:
[hell@local] $ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/hell/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/hell/.ssh/id_dsa.
Your public key has been saved in /home/hell/.ssh/id_dsa.pub.
The key fingerprint is:
f5:b2:f3:2d:43:1b:22:44:98:6c:fe:42: df:a3:15:09 hell@local
[hell@local] $
Los anteriores comandos piden los mismos datos, el primero, en donde salvar la llave privada, si simplemente pulsamos intro, se salvará en la ruta por defecto (la indicada entre paréntesis), a no ser que emplees varias llaves privadas, la ruta por defecto es una buena opción, ya que el cliente la usará sin necesidad de que el usuario tenga que especificarla.
Las siguientes dos cosas que pide son la frase clave con la que encriptar la llave privada y una petición de que se repita la frase para cerciorarse de que no se han cometido errores al escribirla la primera vez. Para la frase con la que encriptar la llave privada se puede emplear cualquier carácter (letras, numeros, signos de puntuación, espacios), en principio el tamaño de la frase puede ser arbitrario, pero ssh-keygen se quejará si es menor de cuatro carácteres. En caso de no introducir ninguna frase, la llave privada quedará sin encriptar, lo cual podria ser útil para realizar algunas automatizaciones como podría ser el realizar copias de seguridad, pero, para uso habitual, se desaconseja dejar las llaves privadas sin encriptar por el peligro que puede representar que estas sean robadas.
A continuación el ssh-keygen muestra donde se ha salvado la llave privada (/home/hell/.ssh/id_dsa) y donde está la llave pública que le corresponde (/home/hell/.ssh/id_dsa.pub ), que no es más que el mismo nombre de archivo con la extensión .pub añadida al final.
En la última línea imprime una huella dactilar que sirve para identificar la llave que acabamos de crear, seguida de un comentario que puede servir para identificar la llave pública.
Añadir llaves públicas a authorized_keys
Despues de haber creado un juego de llaves privada y pública, lo primero es mantener la llave privada secreta, por defecto ssh-keygen establecerá los permisos del archivo con esta llave para que sólo el dueño pueda leerla y modificarla. Por el contrario la llave pública podrá ser leida por cualquier usuario, pues por algo es pública.
Para poder autenticarnos en un equipo remoto con nuestra llave privada, lo único que tendremos que hacer es añadir nuestra llave pública en el archivo .ssh/authorized_keys dentro del directorio personal del usuario al que queremos acceder (generalmente $HOME/.ssh/authorized_keys).
En caso de que podamos acceder a el usando SSH con contraseñas de usuario para autenticarnos, sería mediante SCP, a modo de ejemplo, imaginemos que después de crear el juego de llaves tenemos lo siguiente en nuestro directorio .ssh:
[hell@local] $ ls -1 ~/.ssh
id_rsa
id_rsa.pub
[hell@local] $
No es más que un juego de llaves RSA, ahora la máquina remota donde queremos instalar nuestra llave se llama remoto.ejemplo.com, y la cuenta de usuario es la misma que la que estamos empleando en el sistema que estamos utilizando, entonces podríamos poner:
[hell@local] $ scp ~/.ssh/id_rsa.pub remoto.ejemplo.com:mi_llave.pub
hell@remoto.ejemplo.com's password:
id_rsa.pub 100% 398 0.4KB/s 00:00
[hell@local] $
De esta manera en la máquina remota tendremos el archivo mi_llave.pub que contiene nuestra llave pública, ahora tan sólo nos resta crear el directorio .ssh, en caso de que no exista, y añadir la llave pública al archivo $HOME/.ssh/authorized_keys, para ello, podemos conectarnos mediante SSH y usar el comando cat. Una sesión SSH a modo de ejemplo sería la siguiente:
[hell@local] $ ssh ejemplo.remoto.com
hell@remoto.ejemplo.com's password:
[hell@remoto] $ mkdir .ssh
[hell@remoto] $ chmod 700 .ssh
[hell@remoto] $ cd .ssh
[hell@remoto] $ cat ../my_llave.pub >> authorized_keys
[hell@remoto] $
Ahora, la próxima vez que nos conectemos al servidor remoto.ejemplo.com, en lugar de pedirnos la contraseña del usuario, nos pedira la frase clave con la que la encriptamos nuestra llave privada:
[hell@local] $ ssh ejemplo.remoto.com
Enter passphrase for key '/home/hell/.ssh/id_rsa':
[hell@remoto] $
OpenSSH dispone de varios métodos para verificar la identidad de un usuario remoto, uno de ellos es el uso de contraseñas de usuarios, pero otro de los métodos se basa en la autenticación RSA, en donde se dispone de un juego de llaves privada/pública que garantiza la identidad de un usuario intentando conectarse al equipo remoto. El juego de llaves tiene la propiedad de que lo que se encripta con una, sólo se puede desencriptar con la otra, pero sin embargo, a partir de la llave pública no se puede derivar la llave privada.
Para asegurarse de que un usuario es quien dice ser por medio de criptografía pública OpenSSH emplea el siguiente procedimiento: Primero, el servidor genera un número aleatorio que encripta con la llave pública del usuario y le envia el resultado al cliente, si el usuario es quien dice ser entonces no tendrá ningún problema en desencriptarlo. El cliente aplicará una transformación predefinida a dicho número y lo enviará de vuelta al servidor, el cual, revisará dicho resultado y de ser correcto, dará acceso al cliente.
Configurar el servidor para que acepte llaves públicas.
Lo primero que tendremos que hacer será configurar el servidor de SSH para que las acepte. Los archivos de configuración de OpenSSH se ubican en la carpeta /etc/ssh, el archivo que nos interesa es /etc/ssh/sshd_config, lo abrimos con un editor de textos y corregimos para que queden de la siguiente forma:
#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
RSAAuthentication: sirve para indicar cuando se permitirá autenticación RSA, está opción esta habilitada por defecto, y en el ejemplo está comentada porque sólo sirve para la versión 1 del protocolo SSH.
PubkeyAuthentication: es la que especifica si se podrán usar llaves públicas para demostrar la autenticidad de un usuario. Si su valor es yes como en el ejemplo, entonces se podrán emplear las llaves públicas, si por el contrario su valor es no, entonces el uso de llaves públicas quedará prohibido.
AuthorizedKeysFile: especifica el archivo que contiene las llaves públicas empleadas para la autenticación de los usuarios. Por defecto suele ser el archivo .ssh/autorized_keys, dentro de la carpeta personal de cada usuario.
Finalmente, en caso de haber alterado el archivo de configuración del servidor, para que los cambios sean efectivos, será necesario reiniciar el servidor de SSH.
Crear nuevas llaves
Se pueden generar llaves RSA o DSA para el protocolo SSH versión 2. Para especificar que tipo de llave crear, se emplea el parámetro -t seguido del tipo de llave: "rsa" o "dsa". Por ejemplo, para crear una llave RSA podemos poner:
[hell@local] $ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/hell/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/hell/.ssh/id_rsa.
Your public key has been saved in /home/hell/.ssh/id_rsa.pub.
The key fingerprint is:
c0:40:50:27:e8: d9:b8:55: d6:a4:5f:af:e5:30:5d:9b hell@local
[hell@local] $
Por el contrario, para generar una llave DSA, simplemente:
[hell@local] $ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/hell/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/hell/.ssh/id_dsa.
Your public key has been saved in /home/hell/.ssh/id_dsa.pub.
The key fingerprint is:
f5:b2:f3:2d:43:1b:22:44:98:6c:fe:42: df:a3:15:09 hell@local
[hell@local] $
Los anteriores comandos piden los mismos datos, el primero, en donde salvar la llave privada, si simplemente pulsamos intro, se salvará en la ruta por defecto (la indicada entre paréntesis), a no ser que emplees varias llaves privadas, la ruta por defecto es una buena opción, ya que el cliente la usará sin necesidad de que el usuario tenga que especificarla.
Las siguientes dos cosas que pide son la frase clave con la que encriptar la llave privada y una petición de que se repita la frase para cerciorarse de que no se han cometido errores al escribirla la primera vez. Para la frase con la que encriptar la llave privada se puede emplear cualquier carácter (letras, numeros, signos de puntuación, espacios), en principio el tamaño de la frase puede ser arbitrario, pero ssh-keygen se quejará si es menor de cuatro carácteres. En caso de no introducir ninguna frase, la llave privada quedará sin encriptar, lo cual podria ser útil para realizar algunas automatizaciones como podría ser el realizar copias de seguridad, pero, para uso habitual, se desaconseja dejar las llaves privadas sin encriptar por el peligro que puede representar que estas sean robadas.
A continuación el ssh-keygen muestra donde se ha salvado la llave privada (/home/hell/.ssh/id_dsa) y donde está la llave pública que le corresponde (/home/hell/.ssh/id_dsa.pub ), que no es más que el mismo nombre de archivo con la extensión .pub añadida al final.
En la última línea imprime una huella dactilar que sirve para identificar la llave que acabamos de crear, seguida de un comentario que puede servir para identificar la llave pública.
Añadir llaves públicas a authorized_keys
Despues de haber creado un juego de llaves privada y pública, lo primero es mantener la llave privada secreta, por defecto ssh-keygen establecerá los permisos del archivo con esta llave para que sólo el dueño pueda leerla y modificarla. Por el contrario la llave pública podrá ser leida por cualquier usuario, pues por algo es pública.
Para poder autenticarnos en un equipo remoto con nuestra llave privada, lo único que tendremos que hacer es añadir nuestra llave pública en el archivo .ssh/authorized_keys dentro del directorio personal del usuario al que queremos acceder (generalmente $HOME/.ssh/authorized_keys).
En caso de que podamos acceder a el usando SSH con contraseñas de usuario para autenticarnos, sería mediante SCP, a modo de ejemplo, imaginemos que después de crear el juego de llaves tenemos lo siguiente en nuestro directorio .ssh:
[hell@local] $ ls -1 ~/.ssh
id_rsa
id_rsa.pub
[hell@local] $
No es más que un juego de llaves RSA, ahora la máquina remota donde queremos instalar nuestra llave se llama remoto.ejemplo.com, y la cuenta de usuario es la misma que la que estamos empleando en el sistema que estamos utilizando, entonces podríamos poner:
[hell@local] $ scp ~/.ssh/id_rsa.pub remoto.ejemplo.com:mi_llave.pub
hell@remoto.ejemplo.com's password:
id_rsa.pub 100% 398 0.4KB/s 00:00
[hell@local] $
De esta manera en la máquina remota tendremos el archivo mi_llave.pub que contiene nuestra llave pública, ahora tan sólo nos resta crear el directorio .ssh, en caso de que no exista, y añadir la llave pública al archivo $HOME/.ssh/authorized_keys, para ello, podemos conectarnos mediante SSH y usar el comando cat. Una sesión SSH a modo de ejemplo sería la siguiente:
[hell@local] $ ssh ejemplo.remoto.com
hell@remoto.ejemplo.com's password:
[hell@remoto] $ mkdir .ssh
[hell@remoto] $ chmod 700 .ssh
[hell@remoto] $ cd .ssh
[hell@remoto] $ cat ../my_llave.pub >> authorized_keys
[hell@remoto] $
Ahora, la próxima vez que nos conectemos al servidor remoto.ejemplo.com, en lugar de pedirnos la contraseña del usuario, nos pedira la frase clave con la que la encriptamos nuestra llave privada:
[hell@local] $ ssh ejemplo.remoto.com
Enter passphrase for key '/home/hell/.ssh/id_rsa':
[hell@remoto] $
No hay comentarios:
Publicar un comentario