Entendiendo (y usando) SSH fingerprint 

y asi evitar ataques del tipo 'man in the middle'

ssh es quizás (en mi opinión) la mejor herramienta de comunicación que existe cuando se trata de establecer contacto con un servidor remoto Linux. Al decir remoto, me refiero que puede estar situado en el escritorio de al lado o al otro lado del mundo, en la LAN o en alguna parte de Internet. Claro, el servidor tiene que estar ejecutando el demonio o servicio sshd que normalmente funciona en el puerto 22 (ver el artículo servicios para aprender más sobre como iniciarlo). La ventaja de ssh (Secure SHell, por cierto) es que es seguro, el tráfico entre los equipos es encriptado, estable, robusto, fácil de actualizar y usar, etc. Ha tenido serios bugs como cualquier otro programa pero como buen software open source es rápidamente actualizado en cuestión de horas literalmente, cuando nuevas vulnerabilidades se le conocen, además de que tiene utilerías agregadas como scp y sftp, así como clientes excelentes tanto en Linux y Windows, en fin altamente recomendable su uso en la vida diaria de cualquier administrador o usuario Linux.

¿Si todo es tan maravilloso con ssh?, ¿Entonces cual es el problema?

Muy bien. El escenario es el siguiente para entender bien lo que sucede. El cliente se conecta (por primera vez) digamos desde un equipo Windows con un cliente ssh como puede ser putty (si no usas putty, te estás perdiendo el mejor cliente ssh del mundo) a un servidor Linux y aparece el siguiemte cuadro de diálogo: (algo similar pero en modo de texto aparecería desde una consola de texto):

- mmmmm, ¿Qué diablos es esto?, No tengo tiempo de leer eso, presionaré Si, bien ya entró.

Esto es lo que el usuario común hará al no comprender realmente lo que sucede entre el cliente y el servidor ssh. Al tratarse de un protocolo de comunicación altamente seguro y con tráfico encriptado de punto a punto, entran en juego algoritmos de encriptación. Cada servidor ssh tiene una huella digital única (fingerprint) generada al momento de la instalación. Este fingerprint identifica al servidor en específico. Traduciendo el diálogo anterior diría lo siguiente:

 La llave del servidor anfitrión no está registrada en el registro. Tu
 no tienes garantía que el servidor es la computadora que tu
 piensas que es.
 La clave fingerprint del servidor es:
 1024 63:d1:48:fc:9f:7e:1e:0d:27:d1:7b:23:75:06:34:a2
 Si tu confias en este host, presiona Si para añadir la clave al
 cache de PuTTY y establecer la conexión.
 Si quieres conectarte solo una vez, sin
 añadir la clave al cache, presiona No.
 Si no confias en este host, presiona Cancelar para abandonar la
 conexión.

¿Comienza a quedar claro?, se nos está advirtiendo que el equipo al que queremos conectarnos puede no ser el nuestro, es decir SE TIENE QUE ESTAR SEGURO QUE AL SERVIDOR LINUX QUE ME ESTOY CONECTANDO ES REALMENTE EL MIO y esto solo se logra conociendo previamente el fingerprint del servidor y tenerlo en la Palm, en una nota, o en un papel en la cartera o en un block de notas de la computadora de la casa u otra ubicación, como sea. Si por razones de trabajo u otras, se requiere acceder a un servidor de producción de forma remota ES SUMAMENTE IMPORTANTE CONOCER EL FINGERPRINT DEL SERVIDOR para estar seguro que no me estén interceptando (en un momento se explica esto, calma).

Ok, si, si, pero ¿Como diablos se cuál es el fingerprint de mi servidor?

Ábrete una terminal en tu servidor Linux y te cambias al directorio de configuración de ssh:

#> cd /etc/ssh
#> ls -l
total 173
drwxr-xr-x    2 root root    344 Feb 18 00:18 .
drwxr-xr-x  107 root root   9088 Feb 17 22:57 ..
-rw-------    1 root root 132839 Jan 27 07:51 moduli
-rw-r--r--    1 root root   2517 Jan 27 07:51 ssh_config
-rw-------    1 root root    668 Oct 20 21:26 ssh_host_dsa_key
-rw-r--r--    1 root root    600 Oct 20 21:26 ssh_host_dsa_key.pub
-rw-------    1 root root    525 Oct 20 21:26 ssh_host_key
-rw-r--r--    1 root root    329 Oct 20 21:26 ssh_host_key.pub
-rw-------    1 root root    887 Oct 20 21:26 ssh_host_rsa_key
-rw-r--r--    1 root root    220 Oct 20 21:26 ssh_host_rsa_key.pub
-rw-r-----    1 root root   3482 Feb 18 00:18 sshd_config

Notarás que existen algunos archivos con terminación .pub, pues esta es la parte pública de las llaves de tu servidor ssh pero en forma de un fingerprint, es decir la llave pública generada por los algoritmos dsa o rsa. Generalmente, por default, ssh guarda su llave pública o fingerprint en este caso en el archivo ssh_host_key.pub, si mostramos su contenido se verá lo siguiente:

#> more ssh_host_key.pub
1024 35 161635971725059974812816613188513865727625643323552121445765023013612487474922451108
80703826701959121218181176403629257123317219888287730368486491009806579706597689031242574789
96617659498748196451487737641156043897343204483595648176422701566886723150233655375182156814
44474810364877205687200614515477060949257 root@linux

No nos dice mucho, pero si usamos la herramienta adecuada de las que vienen junto con ssh, se podrá conocer el fingerprint del servidor en un formato de una cadena de números hexadecimales:

#> ssh-keygen -l -f ssh_host_key.pub
1024 63:d1:48:fc:9f:7e:1e:0d:27:d1:7b:23:75:06:34:a2 ssh_host_key.pub

-l  muestra el fingerprint de un archivo
-f  indica el archivo

Nótese que es el mismo fingerprint mostrado por el diálogo de PuTTY con lo que ahora si estamos seguros que es nuestro servidor. En este punto queda claro entonces que la línea anterior es la que deberás conocer previamente y apuntarla y/o traerla contigo de alguna manera para cuando te conectes remotamente a tu servidor Linux estés totalmente seguro que es el tuyo.

NOTA: ssh puede usar dos protocolos: versión 1 y versión 2. La versión 1 es totalmente obsoleta y con algunas vulnerabilidades conocidas y por lo tanto es inseguro y no aconsejable su uso, se incluye por compatibilidad, pero hay que usar el 2. Si usas el protocolo 1 entonces tu archivo de llave privada (del lado del servidor solamente) es ssh_host_key (rsa1).
Si usas el protocolo 2 tus archivos de llave privada son ssh_host_rsa_key y ssh_host_dsa_key que se usan indistintamente por parte de ssh, aumentando asi el nivel de complejidad en el encriptado del tráfico.
Para asegurarte que solo uses la versión 2 de ssh incluye o asegúrate de tener la siguiente línea en el archivo de configuración de ssh (/etc/ssh/sshd_config).

Protcol 2

IMPORTANTE: Obsérvese que cuando hice el ejemplo de arriba, a propósito dejé la línea de la variable Protocol como se queda por default en muchas distros y que es la siguiente:

Protcol 1,2

Aceptando ambos protocolos y en primer lugar toma el 1, como se aprecia perfectamente en el ejemplo, al observar que el fingerprint corresponde al archivo de llave privada de la versión 1. Esto es algo inaceptable en un servidor Web o de producción en alguna empresa, asi que chécalo bien si es que eres el responsable d e los sistemas Linux.

¿Y quien es Man in the middle (MiM) o el hombre intermedio?

Ahora te preguntarás, ¿Si ssh es tan seguro, entonces cual es el riesgo, o porque la necedad de tener que conocer los fingerprints de mis servidores Linux?. ssh es seguro y confiable una vez establecida la comunicación entre el cliente y el servidor, pero en la vida real no todo es tan perfecto y existe una técnica de hackeo (¿o será hacking?) llamada Man in the middle -hombre intermedio-, que consiste en que el hacker (hombre intermedio) se coloca entre dos equipos (cliente y servidor) y el también es un servidor ssh pero obviamente con otro fingerprint distinto al servidor ssh genuino. Entonces, una vez montado el ataque, es decir, lograr que el tráfico del cliente dirigido al puerto 22 del servidor real se desvié al puerto 22 del hacker, este "cachará" los paquetes en su servidor ssh y los reenviará al servidor ssh genuino y cuando este responda al cliente pasará de vuelta por el equipo del hacker, pudiendo este con una herramienta como wireshark "observar" el tráfico entre los dos y como se desencripta lo que reciba/manda para poder ser pasado por su propio servidor ssh, entonces conocerá TODO lo que circula entre los dos extremos pero desencriptado.

Se entiende ahora la importancia de no presionar "Si" de primera instancia porque si algún hacker en nuestra empresa, ciberinternet, escuela, universidad, etc. logró lo anterior, entonces cuando nos conectemos al servidor ssh la primera vez VEREMOS SU FINGERPRINT NO EL NUESTRO, y si lo conocemos previamente entonces es obvio que no es nuestro servidor y no deberemos conectarnos y por supuesto avisar inmediatamente de la situación al administrador de sistemas del lugar.

Generalmente los ataques "Man in the middle" se logran realizar cuando en la red hay switches mal configurados o no monitorizados mediante técnicas conocidas como envenenamiento arp (arp poissoning), que en pocas palabras consiste en lograr que el switch canalize o envié todos los paquetes de todos sus puertos al puerto del hacker. Es decir corrompiendo las tablas arp (la relación de la dirección IP-dirección MAC) del switch. Tal vez las siguientes imágenes clarifiquen esto:

La conclusión importante de todo esto es que SSH ES TOTALMENTE SEGURO Y CONFIABLE, EL PROBLEMA ESTÁ EN LA RELATIVA FACILIDAD PARA REALIZAR SUPLANTACIONES TIPO MAN IN THE MIDDLE, QUE NO ES PROBLEMA DE LA APLICACIÓN SSH Y LA INSEGURIDAD PRODUCIDA ES POR PARTE DEL USUARIO QUE NO VERIFICA EL FINGERPRINT QUE SEA VÁLIDO O CONOCIDO POR ÉL.

¿Cómo hago para ver los fingerprints de los servidores ssh que ya he aceptado?

En Linux, en tu cuenta que uses se genera un directorio oculto llamado .ssh dentro de el encontrarás un archivo llamado known_hosts que si ejecutas el programa ssh-agent:

$> ssh-agent -l -f known_hosts

te dará una lista de los fingerprints de los hosts a los que te has conectado, basta con eliminar el renglón del host que quieras o eliminar todo el archivo para que la siguiente vez que te conectes al servidor ssh te pregunte de nuevo que si lo aceptas o no.

En Windows con PuTTY, en el menú de la ventana de la termina que se abre hay una opción "event log" donde se observa los fingerprints del servidor al que estás conectado. Si buscas en el registro de Windows "putty" te da la siguiente llave:

\HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys

Y es donde deja el registro de los fingerprints que has usado, pero no entiendo como los guarda porque deja una cadena muy larga y no se aprecia el fingerprint realmente, aunque si queda claro el servidor del que pertence, basta con que borres la clave del registro correspondiente y te volverá a preguntar la siguiente vez que te conectes.

Quiero cambiar mis archivos de fingerprint de mi servidor por otros ¿Cómo se hace eso?

Es perfectamente posible y hasta recomendable cada cierto tiempo en un servidor expuesto al Internet por ejemplo, cambiar el fingerprint de ssh. Para hacer esto usaremos nuestra ya conocida herramienta ssh-keygen: Veámoslo por pasos para dejarlo bien claro:

1er. Paso
Cambiarse a /etc/ssh, no tiene que ser forzosamente aqui pero por cuestiones de organización (y por que aqui están las llaves originales) dejemos nuestras nuevas llaves aqui.

#> cd /etc/ssh

2do. Paso
Asumimos que solo se trabajará con el protocolo 2, asi que debemos de generar archivos de llaves para los algoritmos dsa y rsa:

#> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /etc/ssh/mi_llave_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/mi_llave_rsa.
Your public key has been saved in /etc/ssh/mi_llave_rsa.pub.
The key fingerprint is:
e1:40:bb:57:ae:62:dd:bc:a2:3c:3f:35:63:d2:ab:62 root@linux
#>

Se usa la opción -t para indicar el tipo de algoritmo en este caso rsa, se detiene la ejecucción y pregunta por el nombre del archivo donde se guardará la llave privada, indiqué: /etc/ssh/mi_llave_rsa, hay que indicar la ruta completa. Y después pregunta por una contraseña (passphrase), que cuidado!!!!, NO hay que poner nada. Es una llave privada no expuesta a nadie, y ssh en llaves generadas solo para el uso de archivos del mismo servidor necesita NO tener contraseña.

Repetimos lo mismo pero ahora para generar el archivo con dsa:

#> ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): /etc/ssh/mi_llave_dsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/mi_llave_dsa.
Your public key has been saved in /etc/ssh/mi_llave_dsa.pub.
The key fingerprint is:
01:aa:d9:9e:33:f1:ea:50:d4:be:e8:e7:dd:a2:ce:de root@linux
#>

Tenemos ya, entonces, cuatro archivos, dos con las llaves privadas y dos con las llaves públicas, que son las que se exportan al cliente al momento de aceptarse la conexión:

#> ls -l mi_llave*
-rw-------  1 root root 668 Feb 19 00:53 mi_llave_dsa
-rw-r--r--  1 root root 602 Feb 19 00:53 mi_llave_dsa.pub
-rw-------  1 root root 883 Feb 19 00:48 mi_llave_rsa
-rw-r--r--  1 root root 222 Feb 19 00:48 mi_llave_rsa.pub

3er. Paso
Hay que reconfigurar el archivo de configuración de ssh (/etc/sshd/sshd_config) donde agregaremos la variable HostKey dos veces indicando en cada una la ruta y archivos recien creados, veamos el bloque completo de esa parte del archivo de configuración como debe quedar.

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
#HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/mi_llave_rsa
HostKey /etc/ssh/mi_llave_dsa

Obsérvese que aparecen comentadas con un # los archivos de llaves originales, esto es normal, porque son el default.

4to. Paso
Reiniciar el servidor sshd:

#> service sshd restart

O si no se tiene el comando service:

#> /etc/rc.d/init.d sshd restart        
o en algunos distros:       
#> /etc/init.d/sshd restart

Listo es todo, ssh recibió una nueva huella digital que lo identifique.

¿Que pasará si nos conectamos de nuevo desde Windows con el cliente PuTTY?, veamos el mensaje tan apremiante que nos manda:

Es muy distinto al del primer ejemplo. Debido a que ya se tiene almacenado en el cache del cliente la llave pública, su fingerprint, y al no concordar en este intento de conexión , ya que el servidor tiene un nuevo fingerprint, nos lo advierte.
ESTO ES PRECISAMENTE O ALGO MUY SIMILAR LO QUE SE VERÍA SI HAY UN ATAQUE MAN IN THE MIDDLE, ya que previamente nos hemos estado conectando siempre a nuestro servidor sin ningún mensaje, y de repente aparece esto y si no se ha cambiado el fingerprint o nadie aviso nada, cuidado habrá que investigar. Esto es a lo que me refería cuando mencionaba mas atrás que ssh es seguro, lo que no es seguro es que alguien se nos ponga en medio y peor aun que no hagamos caso a los mensajes. En el primer párrafo dice:

 La llave del servidor no concuerda con la que PuTTY tiene
 guardada en su registro. Esto significa que o el
 administrador ha cambiado la llave del host, o que te estás
 conectando a otra computadora que pretende
 ser el servidor.

Mas claro ni el agua.
En fin, en este caso se puede perfectamente apreciar que el fingerprint que muestra el diálogo es el mismo que se generó cuando creamos el archivo con tipo rsa:

e1:40:bb:57:ae:62:dd:bc:a2:3c:3f:35:63:d2:ab:62

Asi que con toda seguridad procedemos a presionar Si, sabiendo que SI es nuestro servidor.

Ojalá te sirva esta ayuda y si tienes dudas, comentarios, ampliaciones del documento, etc. son bienvenidas.