SSH in NAT-Server mit derselben öffentlichen IP-Adresse

16

Ich versuche, SSH von in Büro X zu einigen Linux-Kästen in Büro Y. Die Linux-Kästen in Büro Y sind hinter NAT und jeder laufen auf ihren eigenen Häfen. Ich kann alle erfolgreich über SSH erreichen, aber ich kann mich nicht authentifizieren.

Ich konnte SSH in die erste Box schreiben, aber als ich zur zweiten kam, hieß es:

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

Nach meinem Verständnis wird erwartet, dass von dieser öffentlichen IP-Adresse derselbe Schlüssel angezeigt wird, es wird jedoch ein anderer angezeigt, da es sich um einen anderen SSH-Server handelt.

Wie kann ich das Problem beheben, damit von jedem Server hinter derselben IP-Adresse ein anderer Schlüssel erstellt / akzeptiert wird?

— Kopierlauf starten
quelle

1

+1 für handgezeichnete Wolke.

— JoeG

15

Der Hostname oder die IP-Adresse wird als Hash (oder im Klartext, abhängig von den Optionen und den Standardversionen) in Ihrer known_hostsDatei gespeichert. Die einfachste Lösung besteht darin, für jeden Host einen Eintrag zu DNS oder /etc/hosts(ugh!) - Datei mit derselben IP (WAN) -Adresse hinzuzufügen, z. B . /etc/hosts:

your.wan.ip.address      servera serverb

und dann sshnach Hostname und Port.

— Brandon Xavier
quelle

22

Es gibt einige Möglichkeiten, dies zu beheben:

Sie können die Hostschlüsselprüfung für diesen bestimmten Host deaktivieren. Geben Sie in Ihre ssh_configDatei ( ~/.ssh/config) Folgendes ein:
```
Host remote.host.name
UserKnownHostsFile /dev/null
StrictHostkeyChecking no
```
Dies konfiguriert, sshum niemals Host-Schlüssel für zu speichern remote.host.name, aber der Nachteil ist, dass Sie jetzt für Man-in-the-Middle-Angriffe offen sind (weil Sie blind Host-Schlüssel akzeptieren, von denen Sie nicht wissen, ob sich der Remote-Host-Schlüssel geändert hat).
Sie können eine ähnliche Technik verwenden, um jedem Host einfach eine eindeutige known_hostsDatei zuzuweisen:
```
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
```
Sie stellen dann mit ssh hostaoder eine Verbindung zu diesen Hosts her ssh hostbund sshübernehmen den tatsächlichen Hostnamen und Port aus der Konfigurationsdatei.

— larsks
quelle

4

Nein, das Ändern der /etc/hostsDatei funktioniert auch. Mir gefällt dies besser, weil (a) es keine erweiterten Berechtigungen erfordert und (b) Sie keine Portnummern in der Befehlszeile angeben müssen.

— Larsks

1

In beiden Lösungen ist weiterhin eine Namensauflösung (Hosts oder DNS) erforderlich, um Hosta und Hostb mit der WAN-IP-Adresse zu verknüpfen. Aber beide sind exzellente Vorschläge. Ich war zu faul, um LOL Edit einzugeben. Habe gerade den Hostnamen dort bemerkt - kratz das mit der Namensauflösung.

— Brandon Xavier

2

@CopyRunStart: Sie müssen den Port nicht in der Befehlszeile angeben, da er bereits in Ihrem ~/.ssh/config(für jeden Port ein anderer hosta hostb) angegeben ist, wie in der Antwort von larsks beschrieben. Ebenso können Sie in dieser Konfigurationsdatei verschiedene Benutzernamen, Schlüssel usw. für die verschiedenen Hosts angeben, sodass Sie in der Befehlszeile nur ssh hostanoch ssh hostb

— Folgendes

3

Wenn ich ~ / .ssh / config zweimal upvoten könnte, würde ich. Wenn Sie mit / etc / hosts spielen, kann dies später zu weiteren Problemen bei der Fehlerbehebung führen.

— Aaron

1

Dies ist eine viel bessere Lösung, IMO, als / etc / hosts zu ändern. Als kleines Problem würde ich die HostKeyAliasDirektive verwenden, anstatt die bekannten Hosts auf verschiedene Dateien aufzuteilen . zBHostKeyAlias hosta

— Purpurreiher

8

Sie sagen nicht, welche Solaris-Version (und vor allem SSH) Sie verwenden, aber ausreichend aktuelle Versionen von OpenSSH haben dieses Problem behoben.

Hier sind zwei Einträge von mir known_hosts Datei, die dieselbe IP-Adresse, aber unterschiedliche Portnummern haben (einer ist die implizite 22); Wie Sie sehen können, sind die gespeicherten Schlüssel nicht gleich.

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

Ich weiß nicht, welche Version von OpenSSH dies eingeführt hat, aber ich bin am Laufen

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

— MadHatter unterstützt Monica
quelle

3

Um meinen Kommentar auf @larsks Antwort zu erweitern, halte ich die Verwendung von ~/.ssh/configEinträgen für viel besser als das Ändern von / etc / hosts, obwohl ich HostKeyAliasdie bekannten Hosts lieber auf verschiedene Dateien aufteilen würde . z.B:

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

Und ähnlich für hostb

— Purpurreiher
quelle