SSH en servidores NAT'd en la misma dirección IP pública

16

Estoy tratando de SSH desde la oficina X a algunas cajas de Linux en la oficina Y. Las cajas de Linux en la oficina Y están detrás de NAT y cada una se ejecuta en sus propios puertos. Puedo llegar a todos con éxito a través de SSH, pero no puedo autenticarme.

Pude ingresar a SSH en el primer cuadro, pero cuando llegué al segundo decía:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
[edited out fingerprint]
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:1

Entiendo que espera ver la misma clave de esa dirección IP pública, pero está viendo una diferente porque es un servidor SSH diferente.

¿Cómo puedo solucionarlo para que cree / acepte una clave diferente de cada servidor detrás de esa misma dirección IP?

— Copiar Ejecutar Iniciar
fuente

1

+1 para nube dibujada a mano.

— JoeG

15

El nombre de host o la dirección IP se almacenan como un hash (o en texto plano según las opciones y los valores predeterminados de la versión) en su known_hostsarchivo. La solución más fácil es agregar una entrada para cada host al DNS o al /etc/hostsarchivo (ugh!) Con la misma dirección IP (WAN) como en /etc/hosts:

your.wan.ip.address      servera serverb

y luego sshpor nombre de host y puerto.

— Brandon Xavier
fuente

22

Hay algunas formas de arreglar esto:

Puede deshabilitar la comprobación de claves de host para este host en particular. En su ssh_configarchivo ( ~/.ssh/config), ponga algo como:
```
Host remote.host.name
UserKnownHostsFile /dev/null
StrictHostkeyChecking no
```
Esto configura sshque nunca se almacenarán claves de host remote.host.name, pero la desventaja es que ahora está abierto a ataques de intermediario (porque acepta ciegamente claves de host que no puede saber si la clave de host remota ha cambiado).
Puede usar una técnica similar para simplemente dar a cada host un known_hostsarchivo único :
```
Host hosta
Port 10098
Hostname remote.host.name
UserKnownHostsFile ~/.ssh/known_hosts_hosta

Host hostb
Port 10099
Hostname remote.host.name
UserKnownHostsFile ~/.ssh/known_hosts_hostb
```
Luego se conectará a estos hosts con ssh hostao ssh hostb, y sshtomará el nombre de host y el puerto reales del archivo de configuración.

— larsks
fuente

44

No, modificar el /etc/hostsarchivo también funcionará. Esto me gusta más porque (a) no requiere privilegios escalados y (b) significa que no necesita especificar números de puerto en la línea de comandos.

— larsks

1

La resolución de nombres (hosts o DNS) aún será necesaria en ambas soluciones para asociar hosta y hostb con la dirección IP de WAN. Pero ambas son excelentes sugerencias. Fui demasiado flojo para escribir LOL Edit: acabo de notar el nombre de host allí, tacha eso sobre la resolución de nombres.

— Brandon Xavier

2

@CopyRunStart: no necesita especificar el puerto en la línea de comando porque ya está especificado en su ~/.ssh/config(un puerto diferente para cada uno hosta hostb) como se describe en la respuesta de larsks. Del mismo modo, puede especificar diferentes nombres de usuario, claves, etc. en este archivo de configuración para los diferentes hosts, por lo que todo lo que tiene que hacer en la línea de comandos es ssh hostaossh hostb

— arielf

3

Si pudiera votar ~ / .ssh / config dos veces, lo haría. Jugar con / etc / hosts está destinado a causar otros problemas de solución de problemas en el futuro.

— Aaron

1

Esta es una solución mucho mejor, IMO, que modificar / etc / hosts. Como una pequeña objeción, usaría la HostKeyAliasdirectiva en lugar de dividir los hosts conocidos en diferentes archivos. egHostKeyAlias hosta

— crimson-egret

8

No dice qué versión de Solaris (y, lo que es más importante, SSH) está utilizando, pero las versiones suficientemente actualizadas de OpenSSH han abordado este problema.

Aquí hay dos entradas de mi known_hostsarchivo, que tienen la misma dirección IP pero diferentes números de puerto (uno es el 22 implícito); como puede ver, las claves almacenadas no son las mismas.

[10.69.55.47]:2222 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo+zenWwhFWAa/exdxbm3A3htDFGwFVjFlHLO83AfOaloBbBrr6whmLeDqVPBSwI/yrePClpahLUMYE6qGBFCbbOYiQkMDwacNFfxvxd6oCMDDqZH6NWGiBCt0b2M6YKYhYCw6z8n0yvlLk1eTdpp2OpjbfwAIe4eBkWyKNZY9+17VtzARqGR9tgHC8Dh7HBApDR8wooc+XzY6FhD2b21meIt8r8bjfBIu5t6eQgDHh/TzUT1rGH6W0HeUJxpDnpud5Af1ygMEQFrGrzHi5HKtg+K6HFBggMF8t6p2Dz8oMds5pi6IuPlVi3UvO1X7mMJ9pP7ByMQqiVrQ9wtAbC2QQ==
10.69.55.47 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA1clJ6vp8NDy7D9YVgAKQQzERfx3scR0c0027yOYGGpeLg+nW+x8mJk1ia9GouUTDME+NP2YDVZUEDog9rtTJvuLd22ZxfoC8LGboyBsmlhOVxdSCxmA/+blPCp1pyocr8pXyXjSkb/qQKKQMRoAU7qKKHPfI5Vugj04l6WbW2rJQTqFD/Lguc8AAUOE6K4DNhETOH2gOnwq6xi0vutDmeUKSqEvM/PQFZSlOL4dFDYO5jAUjvgm6yGHP3LlS9fmCzayJgGgLSnNz0nlcd94Pa1Cd441cCAZHFDvDPniawEafH9ok4Mmew0UGopQGUGbfb5+8g8YphLW6aLdrvnZbAw==

No sé qué versión de OpenSSH introdujo esto, pero estoy ejecutando

[me@risby fin]$ ssh -V
OpenSSH_6.9p1, OpenSSL 1.0.1k-fips 8 Jan 2015

— MadHatter
fuente

3

Para ampliar mi comentario a la respuesta @larsks, creo que usar ~/.ssh/configentradas es mucho mejor que modificar / etc / hosts, aunque usaría el en HostKeyAliaslugar de dividir los hosts conocidos en diferentes archivos. p.ej:

Host hosta
Port 10098
Hostname remote.host.name
HostKeyAlias hosta

Y de manera similar para hostb

— garceta carmesí
fuente