Autentificación SSH con cifrado asimétrico usando GPG

Para que la conexión entre cliente y servidor por SSH sea más ágil y rápida, se usa un cifrado simétrico. Sin embargo, para que una conexión con cifrado simétrico sea segura es necesario que ambos interlocutores negocien una clave simétrica usando una conexión segura.

El primer paso para establecer una conexión SSH es que el cliente inicie la conexión con el servidor. Cuando esto ocurre el servidor envía un mensaje aleatorio al cliente cifrado con su clave pública. El cliente debe desencriptar este mensaje con la clave privada del usuario y devolverlo al servidor. El servidor compara el mensaje con el enviado y, si es igual, se verifica la identidad del cliente y se establece la conexión. A partir de este momento, el cifrado de la conexión ya es simétrico.

En una conexión SSH la criptografía asimétrica se usa únicamente para verificar la identidad del cliente y negociar una clave simétrica.

La criptografía simétrica se usa para encriptar el resto de comunicaciones que se producen en ambas direcciones entre cliente y servidor durante la conexión.

Cuando se usa la autentificación por contraseña en una conexión SSH, tras establecer una conexión segura con el servidor remoto, el cliente envía su nombre de usuario y contraseña al servidor remoto para establecer la autentificación. Estas credenciales se comparten a través de un túnel seguro que usa criptografía simétrica entre ambos interlocutores de la comunicación. El servidor verifica las credenciales en su base de datos y, si las encuentra, autentifica al cliente y le permite establecer la comunicación con el servidor.

Cuando se usa la autentificación asimétrica con un par de claves pública y privada, tras establecer la conexión segura con el servidor el cliente comunica el par de claves con el que se quiere identificar frente al servidor. El servidor verifica entonces si existe ese par de claves en su base de datos, generalmente, en el fichero authorized_keys y envía un mensaje encriptado al cliente. El cliente debe desencriptar este mensaje con su clave privada y genera un hash que se devuelve al servidor. Entonces el servidor genera su propio hash y lo compara con el recibido desde el cliente. Si ambas cadenas coinciden, se verifica la autenticidad del cliente y se le permite establecer la comunicación con el servidor.

En el fichero ~/.ssh/known_hosts del cliente se almacenan las huellas de los servidores con los que se ha establecido alguna conexión usando el protocolo SSH. Estas claves son identificadores únicos para cada servidor SSH y permiten que el cliente verifique que el servidor al que se está conectando es el servidor al que verdaderamente tiene intención de conectarse.

El mensaje que aparece la primera vez que un cliente se conecta a un servidor SSH avisa de que la autenticidad del host no puede se demostrada, es decir, indica que no hay constancia de que el servidor al que el cliente se está conectando sea el servidor que realmente dice ser.

Junto a esta advertencia, el mensaje muestra también la huella del servidor SSH, que permite identificarlo de forma única e inequívoca. Tras aportar esta información, se pregunta al usuario si está seguro de continuar con la conexión.

Para contestar a esta pregunta es necesario tener en cuenta varios factores. El primero de ellos es si es la primera vez que se establece una conexión con ese servidor. Si es la primera conexión SSH al equipo, es normal que aparezca este mensaje puesto que la huella del servidor no se ha podido almacenar aún en el fichero known_hosts del cliente. Para verificar la identidad del servidor hay que comprobar que el fingerprint que se muestra en el mensaje realmente coincide con el del servidor.

En cambio, si no es la primera vez que se conecta por SSH a esta máquina, la situación puede ser más delicada. Por una parte este mensaje puede ser totalmente inofensivo si se produce porque algún administrador ha cambiado el par de claves del servidor. Sin embargo, puede ser una situación peligrosa para la integridad de la información que se comparte durante la conexión si el mensaje es resultado de una suplantación del servidor SSH. De esta forma, si un servidor SSH suplanta la dirección IP del servidor al que el cliente se intenta conectar, el protocolo de conexión identificará que la huella del servidor no está almacenada en el fichero known_hosts y, por tanto, mostrará esta advertencia. En este caso, se debe contestar negativamente a la pregunta e interrumpir el intento de conexión.

Un mensaje de advertencia aparece cuando la huella del servidor SSH al que el cliente se está intentando conectar es diferente a la huella del servidor al que se conectó en la misma dirección IP la última vez.

Esta advertencia se muestra cuando la identificación del equipo remoto cambia respecto a la última conexión a la misma dirección IP. El mensaje explica que esta situación se puede deber a una suplantación de la dirección IP del servidor con el que se pretende establecer la conexión SSH o que puede ser consecuencia de un cambio en la clave del servidor.

Para que se produzca este mensaje, es necesario que la revisión estricta esté configurada en el servicio SSH.

Para solventar el problema y poder conectar por SSH al servidor se proponen dos opciones. Por una parte, revisar que, efectivamente, la clave del servidor que está almacenada en el fichero ~/.ssh/known_hosts es la correcta. En el caso de que se haya reutilizado una IP flotante, la solución pasa por borrar la línea del fichero de known_hosts que hace referencia a la huella asociada a la IP flotante reutilizada. Esto se puede hacer con el comando que propone el propio mensaje de advertencia: ssh-keyge -f ~/.ssh/known_hosts -R <Dirección IP>.

En el fichero ~/.ssh/authorized_keys de una máquina se almacenan las claves públicas de los clientes que pueden conectarse a ella por SSH. Durante el establecimiento de la conexión SSH, el servidor usa estas claves públicas para cifrar los mensajes que permiten verificar la autenticidad de los clientes que se intentan conectar a él por el procedimiento que se ha descrito en los apartados 1 y 2 de esta tarea.