SSH dans les serveurs NAT sur la même adresse IP publique

16

J'essaie de SSH depuis le bureau X vers quelques boîtes Linux dans le bureau Y. Les boîtes Linux dans le bureau Y sont derrière NAT et chacune s'exécute sur leurs propres ports. Je peux tous les atteindre avec succès via SSH, mais je ne peux pas m'authentifier.

J'ai pu SSH dans la première case, mais quand je suis arrivé à la seconde, il a dit:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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

D'après ce que je comprends, il s'attend à voir la même clé à partir de cette adresse IP publique, mais il en voit une autre parce que c'est un serveur SSH différent.

Comment puis-je le corriger pour qu'il crée / accepte une clé différente de chaque serveur derrière cette même adresse IP?

— Copier Démarrer le cycle
source

1

+1 pour le nuage dessiné à la main.

— JoeG

15

Le nom d'hôte ou l'adresse IP est stocké sous forme de hachage (ou en texte brut selon les options et les valeurs par défaut de la version) dans votre known_hostsfichier. La solution de contournement la plus simple consiste à ajouter une entrée pour chaque hôte au /etc/hostsfichier DNS ou (ugh!) Avec la même adresse IP (WAN), comme dans /etc/hosts:

your.wan.ip.address      servera serverb

puis sshpar nom d'hôte et port.

— Brandon Xavier
source

22

Il existe plusieurs façons de résoudre ce problème:

Vous pouvez désactiver la vérification des clés d'hôte pour cet hôte particulier. Dans votre ssh_configfichier ( ~/.ssh/config), mettez quelque chose comme:
```
Host remote.host.name
UserKnownHostsFile /dev/null
StrictHostkeyChecking no
```
Cela configure sshpour ne jamais stocker les clés d'hôte remote.host.name, mais l'inconvénient est que vous êtes maintenant ouvert aux attaques de l'homme du milieu (parce que vous acceptez aveuglément les clés d'hôte, vous ne pouvez pas dire si la clé d'hôte distante a changé).
Vous pouvez utiliser une technique similaire pour donner simplement à chaque hôte un known_hostsfichier unique :
```
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
```
Vous vous connecterez alors à ces hôtes avec ssh hostaou ssh hostb, et sshprendrez le nom d'hôte et le port réels du fichier de configuration.

— larsks
source

4

Non, la modification du /etc/hostsfichier fonctionnera également. J'aime mieux cela car (a) il ne nécessite pas de privilèges élevés et (b) cela signifie que vous n'avez pas besoin de spécifier les numéros de port sur la ligne de commande.

— larsks

1

La résolution de noms (hôtes ou DNS) sera toujours requise dans ces deux solutions afin d'associer hosta et hostb à l'adresse IP WAN. Mais les deux sont d'excellentes suggestions que j'étais trop paresseux pour taper dans LOL Edit: Je viens de remarquer le nom d'hôte là-dedans - grattez-le à propos de la résolution de noms.

— Brandon Xavier

2

@CopyRunStart: vous n'avez pas besoin de spécifier le port sur la ligne de commande car il est déjà spécifié dans votre ~/.ssh/config(un port différent pour chacun hosta hostb) comme décrit dans la réponse de larsks. De même, vous pouvez spécifier différents noms d'utilisateur, clés, etc. dans ce fichier de configuration pour les différents hôtes, de sorte que tout ce que vous avez à faire sur la ligne de commande est ssh hostaoussh hostb

— arielf

3

Si je pouvais voter deux fois sur ~ / .ssh / config, je le ferais. Jouer avec / etc / hosts est susceptible de causer d'autres problèmes de dépannage sur la route.

— Aaron

1

C'est une bien meilleure solution, IMO, que de modifier / etc / hosts. En guise de petit problème, j'utiliserais la HostKeyAliasdirective plutôt que de diviser les hôtes connus en différents fichiers. par exempleHostKeyAlias hosta

— crimson-egret

8

Vous ne dites pas quelle version de Solaris (et, plus important encore, SSH) vous utilisez, mais des versions suffisamment à jour d'OpenSSH ont résolu ce problème.

Voici deux entrées de mon known_hostsfichier, qui ont la même adresse IP mais des numéros de port différents (l'un est le 22 implicite); comme vous pouvez le voir, les clés stockées ne sont pas les mêmes.

[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==

Je ne sais pas quelle version d'OpenSSH a introduit cela, mais je cours

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

— Chapelier Fou
source

3

Pour développer mon commentaire sur la réponse @larsks, je pense que l'utilisation d' ~/.ssh/configentrées est bien meilleure que la modification de / etc / hosts, bien que j'utiliserais HostKeyAliasplutôt que de diviser les hôtes connus en différents fichiers. par exemple:

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

Et de même pour hostb

— aigrette cramoisie
source