Summary

  • El RFC 4251 permite guardar localmente la pareja formada por un nombre de servidor y su clave pública, y comparar las claves presentadas en conexiones posteriores.
  • OpenSSH escribe esa memoria en known_hosts. Puede pedir confirmación ante un servidor nuevo, rechazar una clave distinta para uno conocido y aprender claves futuras de un servidor ya autenticado.

La clave de host sirve para que el cliente SSH compruebe con qué servidor está negociando. El problema es anterior a las matemáticas: hay que saber qué clave pertenece al nombre al que se quería llamar. El RFC 4251, de enero de 2006, describe dos maneras de resolverlo. Una es conservar en el propio cliente una lista de nombres y claves; la otra, confiar en una autoridad que certifique esa relación. La lista local ahorra una ventanilla central. También convierte la primera anotación en un acto con consecuencias.

El RFC explica la práctica: aceptar una clave en la primera conexión, guardarla y exigir que las visitas siguientes coincidan. Un intermediario que controle esa primera conversación puede intentar colocar su propia clave en la libreta. Verificar la huella por un canal independiente da contenido a la presentación inicial. Después, la libreta cumple una tarea sencilla y valiosa: advierte cuando la misma dirección se presenta con otra clave.

En OpenSSH, esa libreta se llama ~/.ssh/known_hosts. El manual ssh(1) de OpenBSD explica dónde quedan las claves conocidas y cómo aparece una advertencia destacada si una cambia. Una alerta de cambio no trae un informe policial. Puede haber una sustitución autorizada de claves, una máquina reconstruida o un impostor. El cliente conoce la discrepancia; el operador debe averiguar la causa. La utilidad del aviso reside precisamente en impedir que la diferencia pase por una rutina invisible.

El manual ssh_config(5) enseña tres estilos de primera cita. Con StrictHostKeyChecking=ask, se pregunta antes de añadir un host nuevo y se rechaza uno conocido cuya clave haya cambiado. accept-new inscribe automáticamente a los nuevos, pero también se planta ante una clave cambiada. yes obliga a colocar previamente las claves nuevas. La elección determina quién da el primer visto bueno; la comparación posterior es el rasgo que hace útil a la memoria.

La rotación de claves no tiene por qué empezar con un susto. UpdateHostKeys permite que un servidor ya autenticado envíe claves adicionales. El cliente las incorpora mientras aún confía en la clave anterior. Así, la nueva llave llega acompañada por quien todavía puede abrir la puerta vieja. El orden evita pedirle al desconocido que se avale a sí mismo.

ssh-keyscan recoge claves de host y las entrega en un formato adecuado para la libreta. El propio manual advierte que recogerlas no prueba su autenticidad: alguien situado en la red puede ofrecer una clave distinta. Copiar nombres deprisa no sustituye a comprobar la primera presentación. La memoria de SSH vale porque conserva una historia verificable y hace ruido cuando alguien intenta cambiarla.