Introducción
La gestión de claves públicas y privadas es objeto de confusión en muchas circunstancias, y ello viene determinado por escenarios a veces imprevisibles, a veces mal documentados. De hecho, en muchos casos prácticos, las políticas de seguridad de un entorno específico (un droplet, un VPS, etc.) no permiten cambiar una clave SSH, entre otras cosas porque esta posibilidad socavaría la seguridad del sistema (cualquiera podría cambiarla o hacerse con la propia clave). Y si uno necesitara cambiar esa llave, ¿cómo lo haría?
Es por ello que si, por ejemplo, has configurado el acceso al droplet desde un terminal mediante terminal SSH y clave pública/privada, si accedes con un ordenador (por ejemplo A, el de la oficina) en el que has configurado la encriptación asimétrica, si decides acceder al droplet con otro ordenador tuyo (B, el de casa), no será posible acceder aunque añadas la clave desde el panel de control del VPS.
Qué indica el error Permiso denegado (clave pública).
El error típico en estos casos es de serie:
Permiso denegado (clave pública).
que es un error indicativo hasta cierto punto, al final. Muchos administradores de sistemas entran en crisis con este error, porque no da muchos otros puntos de referencia y simplemente indica que no es posible acceder al sistema remoto utilizando ese tipo de clave. No se reconoce la clave, y ya está: eso es todo lo que sabemos, tenemos que tomar nota y averiguar si no es así.
Si intentamos acceder con el ordenador A al VPS y lo conseguimos, mientras que con el B no, deberíamos leer lo siguiente. La razón del problema, en muchos casos, viene determinada por lo que decíamos al principio: si un droplet está configurado sobre un par de claves (K1, K2) e intentamos acceder a él con cualquier otra clave (K3, K4) distinta de las anteriores, no será posible acceder al servidor remoto a menos que actuemos sobre esta última, es decir, actualizando la clave pública elegible.
Prólogo: qué contiene el fichero authorised_keys
Dentro del fichero del servidor remoto (VPS, droplet, …), en casi todos los entornos Linux, encontraremos de hecho en la carpeta ~/.ssh/ el fichero authorised_keys, es decir
~/.ssh/authorized_keys
que contendrá la lista de claves públicas admisibles (en concreto, la del ordenador A). Lo que vamos a hacer, por tanto, es actualizar la clave pública admisible en el servidor poniendo en cola, como nueva fila, la del ordenador B. Aclarado esto, pasemos a ver el procedimiento paso a paso para actualizar la clave, invitándote a seguirlo con atención sin encontrar términos medios ni trucos inverosímiles, también porque es bueno recordar que la teoría sugiere lo siguiente
el par de claves (K1, K2) sólo funcionará en el ordenador A;
el par de claves (K3, K4) sólo funcionará en el ordenador B;
el par de claves (K1, K3) NO FUNCIONARÁ ni en el ordenador A ni en el ordenador B;
la combinación de teclas (K3, K2) NO FUNCIONARÁ ni en el Ordenador A ni en el Ordenador B.
Cómo añadir una clave pública a un VPS para un equipo
Conecta el ordenador A y el ordenador B a la misma cuenta de Dropbox, por comodidad (opcional pero muy práctico para permitir copiar y pegar entre dos ordenadores diferentes), y luego sigue los pasos que se indican a continuación. Para que quede claro, A ya tiene el par de claves funcionando en el droplet, mientras que B no. Lo que hacemos se dice rápido.
Generar un par de claves pública y privada
Utilizamos ssh-keygen desde el terminal, localmente en el ordenador B, para generar una nueva clave de acceso. Tenga cuidado de introducir una frase de contraseña que sea fácil de recordar, de lo contrario, si la olvida, tendrá que repetir el procedimiento de aquí en adelante.
Abra una ventana de terminal en el ordenador en el que va a obtener acceso a la clave (B) y escriba:
ssh-keygen
Siga paso a paso el mecanismo de generación de claves, teniendo cuidado de especificar un nombre con sentido (si la clave es sobrescrita por varias generaciones sucesivas, siempre se aplica la última, y las demás se pierden para siempre) y de introducir una frase clave fuerte (sólo funcionará desde el ordenador B, y siempre es buena idea usarla por muy vacía que se quede, en teoría). Una vez introducido el nombre del archivo (/Usuarios/NOMBRE/.ssh/id_rsa es la clave por defecto) y elegida/confirmada la frase de contraseña de la clave, se habrán generado los dos puntos de partida del procedimiento
id_rsa que será la clave privada
id_rsa.pub que será la clave pública
Anote la clave pública
Escriba desde el terminal de comandos:
cat ~/.ssh/id_rsa.pub
y copia el resultado del terminal, de nuevo en el ordenador B, en un archivo de texto. Guarda el archivo de texto en Dropbox, para que en el otro lado (A) se sincronice bien (el archivo será key.txt, y debe borrarse al final de las operaciones). Por último, cambia al ordenador A, para que tengas acceso seguro al droplet como haces siempre, por ejemplo con ssh root@ADDRESS_IP.
Copia y pega la clave pública en el droplet
Abre una ventana de terminal de comandos en A, y accede al droplet o VPS: lo que tienes que hacer en este punto es acceder al archivo authorised_keys y pegar el contenido del archivo copy-paste key.txt como última línea.
Para que quede claro:
ssh root@IP_VPS_O_DROPLET
una vez dentro, escribe:
pico ~/.ssh/authorized_keys
y verás una primera línea con la clave ya guardada, ve hasta el final y pon el contenido de clave.txt al final del fichero. Actualización realizada una vez que escriba CTRL O y guardar, por supuesto.
Si ahora vas al ordenador B, también deberías poder acceder al droplet escribiendo aquí:
ssh root@IP_VPS_O_DROPLET
Para estar seguro, recuerda borrar el archivo key.txt o eliminarlo del recurso compartido después de terminar.