Confíe en el servidor SSH basado en la clave en lugar de si la clave + la coincidencia de IP

¿Es posible hacer que al cliente ssh no le importe qué IP está detrás de un servidor ssh (y si un servidor diferente estaba detrás de esa IP antes) sino que confía en claves de servidor específicas? (¿Y quizás apodar esas claves?) Uso DNS dinámico y tengo habilitadas las extensiones de privacidad IPv6 en algunas computadoras y siempre me preguntan si creo que es seguro conectarse. Otra posibilidad es que las direcciones asignadas por DHCP se asignen a diferentes servidores ssh y provoquen todo tipo de errores de 'clave no coincida con IP'.

ssh

— Azendale
fuente

Probablemente debería haber mencionado también que tengo una lista de claves públicas para cada uno de mis servidores ssh en una página web que se sirve a través de SSL, por lo que tengo una manera fácil de verificar si realmente confío en un conjunto de claves de servidor específico.

— Azendale

Respuestas:

Agregue un apodo para su servidor ~/.ssh/configy desactívelo CheckHostIPpara este servidor.

Host nickname
HostName example.dyndns.org
CheckHostIP no

Antes de conectarse al servidor por primera vez, puede copiar la clave pública fuera de banda: tome /etc/ssh/ssh_host_rsa_key.pubdel servidor, elimine la root@hostnameparte al final de la línea, agregue example.dyndns.orgal principio y agregue la línea a ~/.ssh/known_hosts. Opcionalmente, ejecute ssh-keygen -Hpara codificar el nombre de host (esto solo es útil si le preocupa la privacidad de esa entrada si alguien roba su disco duro o sus copias de seguridad, lo que para el 99.99% de las personas es inútil porque la información está presente en alguna otra ubicación cercana ubicación de todos modos).

— Gilles 'SO- deja de ser malvado'
fuente

Con el Host nickname, ¿eso significa que puedo hacerlo ssh nickname? Si es así, eso es bastante bueno.

— Azendale

@Azendale: Exactamente, esa es una característica general para dar un apodo a un nombre de host y un conjunto de opciones (nombre de usuario, opciones booleanas, túneles, ...).

— Gilles 'SO- deja de ser malvado'

En /etc/ssh/ssh_configagregar la línea

CheckHostIP no

Sin embargo, esto le quita un poco de seguridad en SSH, porque cualquier máquina puede esconderse detrás de la IP o el nombre DynDNS al que se conecta.

— htorque
fuente

Esto no quita ninguna seguridad en absoluto. El objetivo de almacenar la clave de host es identificar la otra computadora. El nombre y la dirección IP no son relevantes para la seguridad cuando tiene la clave de host. Eliminar los mensajes espurios es de hecho una ganancia para la seguridad (los mensajes espurios consumen su atención, que es un recurso escaso).

— Gilles 'SO- deja de ser malvado'

@Gilles: Las páginas de manual no está de acuerdo. Sí, no pierde ninguna seguridad para las conexiones donde no existe una relación IP-host conocida, en otros casos, renuncia a la protección contra ataques de suplantación de identidad (como se indica en la página de manual).

— htorque

No sé a qué pasaje de la página de manual te refieres. Si es la descripción de CheckHostIP, entonces no, no dice que renuncies a ninguna protección. Con CheckHostIP no, el spoofer todavía tiene que obtener la clave privada del servidor, y si puede hacerlo, es poco probable que de todos modos no pueda falsificar su dirección IP.

— Gilles 'SO- deja de ser malvado'

¿Me puede dar un ejemplo de cómo la falsificación de DNS sería peligrosa si sé que confío en la clave? Utilizo la autenticación de clave pública para iniciar sesión, lo que hace que un servidor malintencionado no pueda obtener una contraseña, pero ¿y si utilizo contraseñas?

— Azendale

El uso de la autenticación de clave pública no protege realmente su contraseña, el servidor podría MITM y obtener su contraseña cuando usted sudoo similar.

— Remram