Tengo una configuración de inicio de sesión de clave de host ssh en un servidor remoto, por alguna razón, el DNS de ese host se asigna a otro servidor.
Supongamos que no se puede confiar en el host erróneo, ¿debo cambiar mi clave?
Cuando se conecta al servidor incorrecto, esto debería provocar una advertencia muy notable por parte del cliente, ya que el servidor parece usar una clave distinta de la clave que estaba usando en las sesiones anteriores. El cliente recuerda las claves de los servidores. Para un cliente OpenSSH clásico, la advertencia es así:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
Por supuesto, esto depende de que su cliente ya se haya conectado al menos una vez al servidor correcto; de lo contrario, el cliente no sabrá de antemano la clave de servidor correcta.
Suponiendo que usted hizo "hizo clic en" la advertencia (es decir, modificó su .ssh/known_hosts para evitarla), entonces se conectó al servidor incorrecto. Al usar la autenticación basada en clave, el cliente calcula una firma digital en una cadena que contiene el "hash de intercambio de clave", una valor específico de sesión obtenido del mecanismo de intercambio de claves a través de una función hash; el servidor verifica la firma con respecto a la clave pública del cliente esperado (en .ssh/authorized_keys ).
De ninguna manera la clave privada del cliente se revela al servidor. Además, la inclusión del hash de intercambio de claves en el que está firmado evita que el servidor receptor (el incorrecto / falso) reutilice la firma para hacerse pasar por el usuario en el servidor correcto. Por lo tanto, la clave privada de su cliente es segura; no hay necesidad de cambiarlo.
(El mecanismo de autenticación de cliente basado en clave se describe en sección 7 de RFC 4252 .)
Si le preocupa haber filtrado su clave privada, en ningún momento su clave privada se envía al otro servidor. Como Thomas explica en su respuesta ¿Cómo funciona la autenticación de clave pública ssh? :
El concepto central sigue siendo el mismo: el cliente demuestra su control de la clave privada mediante la realización de una operación que requiere el conocimiento de esa tecla, pero tal que la operación "inversa" se puede hacer con el clave pública que se encuentra en .ssh / authorized_keys en el servidor.
Lea otras preguntas en las etiquetas public-key-infrastructure ssh ssh-host-key