¿Cómo editar conocido_hosts cuando varios hosts comparten el mismo nombre de IP y DNS?

29

Regularmente ssh en una computadora que es una computadora OS X / Linux de arranque dual. Las dos instancias del sistema operativo no comparten la misma clave de host, por lo que pueden verse como dos hosts que comparten la misma IP y DNS. Digamos que la IP es 192.168.0.9, y los nombres son hostnameyhostname.domainname

Según tengo entendido, la solución para poder conectarse a los dos hosts es agregarlos al ~/.ssh/know_hostsarchivo. Sin embargo, es más fácil decirlo que hacerlo, ya que el archivo es ordenado, y tiene probablemente varias entradas por host ( 192.168.0.9, hostname, hostname.domainname). Como consecuencia, tengo la siguiente advertencia

Warning: the ECDSA host key for 'hostname' differs from the key for the IP address '192.168.0.9'

¿Hay una manera fácil de editar el known_hostsarchivo, manteniendo los hash? Por ejemplo, ¿cómo puedo encontrar las líneas correspondientes a un hostame dado? ¿Cómo puedo generar los hashes para algunos hosts conocidos?

La solución ideal me permitiría conectarme sin problemas a esta computadora con ssh, sin importar si lo llamo o no 192.168.0.9, hostnameo hostname.domainnamesi usa su clave de host Linux o su clave de host OSX. Sin embargo, todavía quiero recibir una advertencia si hay un verdadero ataque de hombre en el medio, es decir , si se usa una clave diferente a estas dos.

ssh openssh

— Frédéric Grosshans
fuente

Qué es lo que quieres hacer? ¿Editarlo para qué?

— Rhyuk

@Rhyuk: edítelo para poder reconocer como válidas la clave de host OSX y Linux para la dirección IP, el nombre de host y el nombre de host.domainname.

— Frédéric Grosshans

@Rhyuk: he editado la pregunta. ¿Está más claro ahora?

— Frédéric Grosshans

2

¿Simplemente ha considerado hacer que ambas instalaciones tengan la misma clave?

— Zoredache

3

Hay algunos casos en los que es razonable usar una dirección IP para acceder a varias entidades (cada una con claves de host SSH individuales) y aún mantener un control estricto de que SOLO esas claves de host son las que ve el cliente SSH. Por ejemplo, algunas configuraciones de alta disponibilidad donde se accede a un grupo de unidades usando una dirección IP compartida pero donde (por alguna razón) la clave de host SSH vista por los clientes cambia según la unidad de grupo que esté actualmente activa. Otro caso es cuando varios hosts SSH están detrás de un firewall NAT y se accede desde el exterior, todos parecen tener la misma IP.

— IllvilJa

12

La solución más sencilla aquí es usar las mismas claves de host para Linux y OS X. Es decir, elegir un conjunto de /etc/ssh/ssh_host_*_key*archivos y copiarlos al otro sistema operativo. Luego, la misma clave de host se presentará a un cliente SSH independientemente del sistema operativo en el que haya arrancado, y el cliente SSH no será más sabio.

— jjlin
fuente

Prefiero una versión de cliente, pero probaré esta si no la encuentro. Por cierto, la localización OSX (no estándar) de los archivos /private/etc/ssh_host*no lo es /etc/ssh/ssh_host*.

— Frédéric Grosshans

Copiar los archivos de una máquina a otra (dos máquinas Linux) no funcionó para mí. Aunque el contenido del archivo era idéntico, el hash no lo era, así que todavía recibía el problema (¿tal vez la hora de modificación?). La solución a continuación es mucho mejor.

— Stav

sshdcarga las claves de host una vez al inicio, por lo que es probable que deba reiniciar sshd. Agregaré eso a la respuesta. En cuanto a que otras soluciones sean mejores, depende de su situación. Yo diría que las principales ventajas de este método es que solo requiere una configuración única y es más probable que funcione con múltiples implementaciones de clientes SSH.

— jjlin

Curiosamente, parece que mi relativamente reciente OpenSSH 7.4p1 sshdcarga claves de host en cada nueva conexión. Tal vez ha sido así durante mucho tiempo y simplemente asumí que las claves de host se trataron como otra sshdconfiguración. De todos modos, ese puede o no ser tu problema.

— jjlin

¿Sería una mala idea hacer esto a dos hosts en un clúster que comparten la misma dirección VRRP? En la conmutación por error, el host que responde será diferente. Me gustaría no recibir la advertencia.

— Colin 't Hart

26

Como @Izzy sugirió en un comentario anterior, ssh te dice la línea ofensiva, y al eliminar esa línea, (guardarla en otro lugar), aceptar la nueva clave y luego copiar la línea eliminada, terminas con dos claves para la misma host, y ssh aceptará cualquiera de los dos.

(También puede usar ssh-keygen -H -F <hostname>para buscar líneas en su archivo conocido_hosts que coincidan con ese nombre de host. Ejecutar esto después de copiar la línea eliminada de nuevo debería enumerar dos entradas).

Si alguien sabe cómo hacer que PuTTY haga lo mismo, me interesaría saberlo.

— DaCheetah
fuente

44

En realidad, si tiene un cliente de Linux, ni siquiera necesita eliminar la línea ofensiva, solo tiene que comentarlo con un carácter hash ('#') al frente. Luego, una vez que haya aceptado la nueva clave, puede editar el archivo known_hosts y descomentar la línea con la clave anterior. Pero sí, esto también sería útil en Putty.

— IllvilJa

1

Si hay dos hosts con el mismo nombre, pero con una dirección IP diferente y una clave de host diferente, esta solución también funciona: comente (o elimine temporalmente), entonces ambas líneas para ese host (la basada en la dirección IP y la basada en el host nombre), conéctese al host aún no conocido y luego vuelva a agregar las líneas que fueron comentadas o eliminadas.

— Kai Petzke

13

Encontré esto que puede ayudarte con lo que quieres lograr.

Fuente: /programming/733753/how-to-handle-ssh-host-key-verification-with-2-different-hosts-on-the-same-but

Cree un archivo de configuración en su directorio .ssh de la siguiente manera:
Host server1
  Hostname x1.example.com
  HostKeyAlias server1
  CheckHostIP no
  Port 22001
  User karl

Host server2
  Hostname x2.example.com
  HostKeyAlias server2
  CheckHostIP no
  Port 22002
  User karl
Explicación a continuación (de man ssh_config)

CheckHostIP

Si este indicador se establece en "yes", ssh (1) verificará adicionalmente la dirección IP del host en el archivo known_hosts. Esto permite que ssh detecte si una clave de host cambió debido a la falsificación de DNS. Si la opción se establece en "no", la verificación no se ejecutará. El valor predeterminado es "sí".

HostKeyAlias

Especifica un alias que debe usarse en lugar del nombre de host real al buscar o guardar la clave de host en los archivos de la base de datos de claves de host. Esta opción es útil para tunelizar conexiones SSH o para múltiples servidores que se ejecutan en un solo host.

La línea de nombre de usuario y puerto evita que tenga que dar esas opciones en la línea de comando, por lo que puede usar:
% ssh server1
% ssh server2

— Rhyuk
fuente

Vi este artículo, pero no corresponde a mi caso: los dos servidores se distinguen por número de puerto en el artículo, no en mi caso. Además, me gustaría mantener las capas adicionales de seguridad aportadas por los hashes salados known_hostsy CheckHostIP.

— Frédéric Grosshans

1

@ FrédéricGrosshans, compruebo marcado No tiene que tener puertos separados, y la opción HashKnownHosts funciona bien con HostKeyAlias.

— Zoredache

La desventaja de esto es que, a menos que me equivoque, esto se configura por cliente frente a que la respuesta aceptada se configura solo en los servidores ssh que aceptan.

— FreeSoftwareServers

2

La forma más fácil de resolver su problema es dar a cada host una dirección IP propia / distinta. Con 253 direcciones disponibles en su red (privada) e IPv4, eso no debería ser gran cosa. Déles direcciones IP fijas (ya que un servidor DHCP identificaría la máquina en función de la dirección MAC de las tarjetas de red, y ambas obtendrían la misma dirección). No veo ninguna otra solución si desea mantener las medidas de seguridad (que tampoco descartaría por esa pequeña "comodidad").

— Izzy
fuente

En realidad, la dirección IP no 192.168.0.xxes y no es privada. Es una dirección IPv4 'real', dada por mi universidad y que no puedo cambiar.

— Frédéric Grosshans

Si verifica con Wikipedia , verá 192.168.0.0 - 192.168.255.255 (su pregunta especificada 192.168.0.9, que se encuentra dentro de este rango) pertenece a los "espacios de direcciones IPv4 privadas". Entonces, por "privado" no me referí a ti como "dueño", sino a las especificaciones del IETF . En su pregunta, no indicó que no puede cambiar la IP, lo siento, pero con la entrada dada, mi respuesta fue adecuada.

— Izzy

Perdón por la pregunta mal formulada. No voté en contra.

— Frédéric Grosshans

No hay problema, y gracias por avisarme, hace que el voto negativo sea menos desalentador. Pero otra idea: no estoy seguro de dónde el archivo known_hosts toma el nombre de host, DNS inverso u ofrecido por el cliente. Puede intentar cambiar el nombre de uno de sus "hosts" para que presente un nombre de host diferente. O para que se agreguen ambas claves de host: ssh le indica la "línea ofensiva" en su archivo conocido_hosts (cuando el n. ° 1 está contenido y se conecta con el n. ° 2). Entonces, podría copiar esa línea a otro archivo, eliminarla de conocido_hosts, dejar que el # 2 se conecte y agregar su línea, y agregar la línea eliminada nuevamente. No estoy seguro si funciona, pero puedes intentarlo.

— Izzy

2

No me encuentro con ese problema cuando me conecto a varias cajas VPS que comparten la misma IP porque cada una tiene un puerto SSH diferente (20022,30022, etc.) por lo que están registradas como hosts conocidos con diferentes claves.

¿Podría ser una solución para usted?

— Pyheme
fuente

Hola @Pyheme, ¡bienvenido a Super User! Tenga en cuenta que esta pregunta tiene casi 4 años. No hay nada de malo en responderla, pero tenga en cuenta que es posible que no obtenga una respuesta.

— Hewbot

Ya no tengo ninguna máquina OS X, pero su respuesta podría ser útil para otra persona. Ese es el objetivo del intercambio de

— fichas

@Hewbot ... de hecho, lo veo ahora. No sé por qué, apareció en la lista de preguntas recientes ...

— Pyheme

1

Otro artículo , que describe varias formas de manejar su problema:

El segundo método usa dos parámetros openSSH: StrictHostKeyCheckiny UserKnownHostsFile. Este método engaña a SSH configurándolo para usar un archivo empty_hosts vacío y NO para pedirle que confirme la clave de identidad del host remoto.

— afk
fuente

Este documento trata sobre no permitir la verificación de claves. Quiero mantener la clave comprobada, y no quiero rechazarla cada vez que hostnamese reinicie en Linut o OSX

— Frédéric Grosshans

1

¡Bienvenido a Super User! Si bien esto puede responder teóricamente la pregunta, sería preferible incluir aquí las partes esenciales de la respuesta y proporcionar el enlace para referencia. He incluido una breve parte, pero podría no ser lo que pretendías ...

— Tamara Wijsman

1

Como desea mantener la estricta comprobación de la clave del host, quisiera que usaran diferentes known_hostsarchivos. Para hacer esto, configure su ~/.ssh/configarchivo (o el /etc/ssh/ssh_configarchivo si necesita que funcione en múltiples cuentas de usuarios locales) de esta manera:

Host myserver.osx
  UserKnownHostsFile ~/.ssh/known_hosts.dual.osx
  # default is ~/.ssh/known_hosts
  Hostname $REALHOSTNAME

Host myserver.linux
  UserKnownHostsFile ~/.ssh/known_hosts.dual.linux
  Hostname $REALHOSTNAME

, reemplazando $REALHOSTNAMEcon el nombre de host real o la dirección IP, por supuesto. (No importa cuál elija, siempre y cuando elija algo después del "Nombre de host" que resolvería en la dirección IP, pero usaría el nombre de host en lugar de una dirección IP, solo por principios generales).

Entonces, ssh myserver.linuxy por ssh myserver.osxlo tanto, puede tener diferentes claves de host, pero aún así obtiene la comprobación. Si Linux está activo y escribe OS X (o viceversa), recibirá la advertencia (que creo que es el efecto deseado).

Si tuviera este problema, me aseguraría de que hubiera algo completamente incorrecto en el known_hostsarchivo principal que no coincida con ninguno de los dos, de modo que si escribe en $REALHOSTNAMElugar de myserver.osxrecibir la advertencia. :-) Lo haría poniendo algo como

<ip-address-of-github.com> $REALHOSTNAME

en mi /etc/hosts, luego haciendo una ssh $REALHOSTNAMEy aceptando la nueva clave, luego sacando esa entrada.

— Jim
fuente