Esta chuleta está resultando muy util para los proyectos de BigData donde se necesita arrancar procesos en máquinas remotas. La idea es entrar en las máquinas mediante ssh sin necesidad de introducir una password. Tiene, como todo, ventajas, como las que indicamos de levantar servicios o procesos remotos, e inconvenientes, como por ejemplo que si cae la password de una máquina, caen automáticamente todas las que tengan este ssh sin password.
Para generar esta posibilidad de login sin password, comenzamos generando un par de claves, pública y privada:
ssh-keygen -t rsa
[root@spark1 ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
chorronumeros:XX:XX root@spark1
The key’s randomart image is:
+–[ RSA 2048]—-+
…
[root@spark1 ~]#
Esto nos genera dos ficheros en ~/.ssh/, id_rsa y id_rsa.pub. La primera es la clave privada y la segunda es la clave pública.
El siguiente paso será copiar esa clave pública en las máquinas destino.Primero creamos el directorio .ssh por si no existe:
[root@spark1 ~]# ssh root@spark2 mkdir ~/.ssh
root@spark2’s password:
mkdir: cannot create directory ‘/root/.ssh’: File exists
[root@spark1 ~]#
Y añadimos el contenido de la clave pública del usuario en el fichero authorized_keys en la máquina remota:
[root@spark1 ~]# cat .ssh/id_rsa.pub | ssh root@spark2 ‘cat >> ~/.ssh/authorized_keys’
root@spark2’s password:
[root@spark1 ~]#
En condiciones normales nos debería dejar entrar con ssh sin problemas en la segunda máquina:
[root@spark1 ~]# ssh spark2
Last login: Thu Nov 17 21:10:49 2016 from spark1
[root@spark2 ~]# logout
Connection to spark2 closed.
[root@spark1 ~]#
Si este proceso falla, tendremos que entrar en la máquina remota y averiguar un par de cosas, como por ejemplo cuál es el fichero donde se almacenan las claves autorizadas:
/etc/ssh/sshd_config:
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys
También sería conveniente, en caso de que esta parte no sea el origen del problema comprobar los permisos de ficheros:
El directorio ~/.ssh debería tener permisos 700 y ~/.ssh/authorized_keys debería tener 640