Cuando se conecta por primera vez a un servidor SSH determinado, obtiene la pregunta habitual con la huella digital clave; posteriormente, el cliente SSH almacena una copia de la clave pública del servidor en el archivo .ssh/known_hosts . Pero el cliente SSH realmente almacena dos claves: una para el servidor nombre y otra para el servidor IP .
Por ejemplo, suponga que el servidor foo.example.com tiene IP 10.0.0.8 . En su primera conexión ( ssh foo.example.com ), el cliente SSH obtendrá la clave pública del servidor, mostrará la huella digital (un hash de la clave pública), solicitará confirmación y luego almacenará en el archivo known_hosts dos asignaciones, una para foo.example.com , el otro para 10.0.0.8 , ambos apuntando a la misma clave pública.
Cuando se conecta de nuevo al mismo servidor, SSH verifica las dos asignaciones. Si la primera asignación (la del nombre) produce una clave pública que es distinta de la registrada en known_hosts , aparece el mensaje de error con UPPERCASE LETTERS (así es como se asusta) y el cliente se niega para seguir conectando (por lo que el mensaje no solo da miedo, también es bastante inconveniente).
Otra situación es cuando la primera asignación coincide:
- Los tipos de usuario:
ssh foo.example.com .
- El sistema DNS resuelve ese nombre a IP
10.0.0.8 .
- El cliente SSH se conecta a esa máquina y obtiene la clave pública del servidor SSH.
- La clave pública obtenida coincide con la que se encuentra en
.ssh/known_hosts en la entrada foo.example.com .
-
PERO la clave pública obtenida NO coincide con la encontrada en
.ssh/known_hosts bajo la entrada 10.0.0.8 .
En ese caso, recibe el mensaje exacto que muestra en su pregunta. El cliente de SSH tiene cierta seguridad de que está hablando con el servidor deseado (la clave pública coincide con la registrada para el mismo servidor nombre ), pero algo sigue sin estar bien, por lo tanto, la advertencia y la confirmación pronta.
Esto puede suceder cuando la IP del servidor ha cambiado. Con el ejemplo anterior, supongamos que, la semana pasada, foo.example.com tuvo IP 10.0.0.7 , pero bar.example.com tuvo IP 10.0.0.8 . En ese momento, te conectaste a ambos. Pero el fin de semana pasado, un administrador de sistemas con un ligero trastorno obsesivo compulsivo decidió que había que cambiar algo de IP, para que pudiera establecer reglas de red más eficientes, regulares y matemáticamente elegantes. Así que "movió los servidores" y estableció bar.example.com en IP 10.0.0.16 y foo.example.com en 10.0.0.8 . Nuestro amigo el administrador del sistema configuró debidamente el DNS para informar la nueva IP. Ahora, estamos el lunes y quieres volver a conectarte. Su cliente SSH habla con el DNS, obtiene la nueva IP para foo.example.com , y todo está bien, excepto que la clave registrada para 10.0.0.8 no coincide con la clave pública de foo.example.com : de hecho , su archivo known_hosts contiene una copia de la clave pública de bar.example.com , listada bajo la IP 10.0.0.8 , la cual, hasta la semana pasada, fue la IP de bar , no la de foo .
Un administrador de sistemas con OCD no es estrictamente necesario para este escenario; también puede ocurrir con configuraciones dinámicas de IP, o con algunos casos de balanceo de carga.
Solución: use un editor de texto y elimine la entrada ofensiva de su known_hosts (línea 14, en su caso). También puede usar el comando ssh-keygen -R <host> para eliminar la entrada en particular. La próxima vez que se conecte, el cliente mostrará otra advertencia (esta vez quejándose de la ausencia de cualquier clave pública registrada para la IP de destino), pero esta pasará casi desapercibida, porque habrá no ser pronta en absoluto. El cliente SSH grabará la clave pública nuevamente en known_hosts , y arreglará las cosas, al menos hasta que el administrador del sistema escuche voces otra vez .
Alternativamente, deshabilite la comprobación de IP del host en el cliente SSH, configurando la opción CheckHostIP en no (en el /etc/ssh/ssh_config de todo el sistema, o su .ssh/config , o directamente en la línea de comandos:% código%). Las verificaciones de IP del host son útiles para detectar situaciones anormales de nombres de servidores errantes, pero para algunos administradores de sistemas, la combinación de IP del servidor es perfectamente "normal".