Por Internet hay muchos tutoriales que dicen lo mismo que este, como conectar dos máquinas mediante SSH sin contraseña.
Para ello, a grandes rasgos, lo que hay que hacer es copiar una clave pública del sistema local en el sistema remoto para que cuando se inicie la conexión, el sistema remoto pueda confiar en el sistema local.
Antes de nada, hay que tener un par de claves pública y privada que se pueden generar así:
usuario@servidor-local:~:$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/usuario/.ssh/id_rsa):
Created directory ‘/home/usuario/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/usuario/.ssh/id_rsa.
Your public key has been saved in /home/usuario/.ssh/id_rsa.pub.
The key fingerprint is:
3a:4b:0c:7d:3e:9f:9a:7b:3c:ad:ee:5f:3a:bb:3c:ed usuario@servidor-local
usuario@servidor-local:~:$
No es necesario introducir la passphrase (contraseña de encriptación de propia clave) ya que sino nos la pediría cada vez que intentamos usar la clave. Aunque esto también se pueden solucionar mediante el comando ssh-add, pero en eso no me voy a meter.
Después de tener nuestro par de claves, debemos copiar nuestra clave pública, nunca la privada que para eso es privada, al servidor remoto donde queremos conectarnos sin necesidad de introducir la contraseña. Esto es para que el servidor remoto confíe en nosotros en los intentos de conexión al tener nuestra clave pública (en los intentos de conexión se envía la clave privada). Para ello se puede ejecutar el siguiente comando:
usuario@servidor-local:~:$ scp .ssh/id_rsa.pub usuario@servidor-remoto:
Después de copiarla hay que introducirla en la lista de claves públicas en las que el servidor remoto confía:
usuario@servidor-local:~:$ ssh usuario@servidor-remoto
usuario@servidor-remoto’s password:
usuario@servidor-remoto:~:$ ls
id_rsa.pub
usuario@servidor-remoto:~:$ cat id_rsa.pub >> .ssh/authorized_keys
usuario@servidor-remoto:~:$ exit
usuario@servidor-local:~:$
A partir de ahora ya podemos conectarnos desde nuestro servidor local a nuestro servidor remoto, siempre con el usuario para el cual hemos generado las claves, sin necesidad de introducir la contraseña.
Por supuesto, si queremos conectarnos desde el servidor remoto al servidor local sin necesidad de introducir la contraseña, hay que realizar los mismos pasos pero con las máquinas cambiadas.
Esto es muy útil cuando tienes que administrar varios servidores con diferentes contraseñas de forma continuada y no tienes ganas de aprendértelas todas. Eso sí, ya que no las vas a usar a menudo, apúntalas en algún programa del tipo KeePass porque si se te olvida la contraseña de root y pierdes las claves entonces sí que tienes un problema.
Pero es que hay veces que después de hacer toda esta parafernalia en un sentido (local » remoto) y todo funcione correctamente, la haces en el sentido contrario (remoto » local) y no va. Y te rompes la cabeza, y regeneras las claves veinte veces, y revisas el archivo authorized_keys, y revisas la copia de id_rsa.pub, incluso copias la clave privada… y nada. Y el caso es que en el otro sentido sí funciona…
Pues a buscar en Internet y a leer la documentación. Pero si todo lo has hecho igual y no funciona ¿por qué? Pues nada. Último recurso: leer los mensajes de depuración en /var/log/auth.log a ver qué encuentras. Además, si al comando ssh le pones el parámetro -v pues imprime todo lo que va haciendo cuando conecta. Puedes llegar a poner hasta tres uves: -vvv.
Y es aquí donde, por fin, encuentras que tu servidor remoto se encuentra en una lista negra en tu servidor local. Sí, una lista negra que se encuentra en los archivos /etc/ssh/blacklist.RSA-2048 y /etc/ssh/blacklist.DSA-1024.
Esta lista se crea generalmente cuando se cambia de máquina y a la que normalmente conectas y se le pone el mismo nombre. La primera vez te pide a ver si realmente quieres conectar, pero hay veces que para evitar la suplantación de identidades pues parece ser que mete las huellas de las máquinas sospechosas en listas negras.
Borrando estos archivos se consigue que las conexiones sin contraseña vuelvan a funcionar sin problemas.
Pero bueno, todo esto es lo que tiene cuando algún desarrollador de Debian mete la pata. Pero vamos, no hay problema. Estas cosas pasan hasta en las mejores familias. A ver si a partir de ahora nos evitamos algún que otro dolor de cabeza.
