SSH na serwery NAT na tym samym publicznym adresie IP

16

Usiłuję SSH z biura X do kilku urządzeń Linux w biurze Y. Urządzenia Linux w biurze Y są za NAT i każdy z nich działa na swoich własnych portach. Mogę z powodzeniem dotrzeć do wszystkich za pośrednictwem protokołu SSH, ale nie mogę się uwierzytelnić.

Byłem w stanie SSH w pierwszym polu, ale kiedy dotarłem do drugiego, powiedział:

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

Rozumiem, że oczekuje tego samego klucza z tego publicznego adresu IP, ale widzi inny, ponieważ jest to inny serwer SSH.

Jak mogę to naprawić, aby tworzył / akceptował inny klucz dla każdego serwera za tym samym adresem IP?

— Kopiuj Uruchom Start
źródło

1

+1 za ręcznie rysowaną chmurę.

— JoeG,

15

Nazwa hosta lub adres IP są przechowywane jako skrót (lub jako zwykły tekst w zależności od opcji i ustawień domyślnych wersji) w known_hostspliku. Najłatwiejszym obejściem jest dodanie wpisu dla każdego hosta do /etc/hostspliku DNS lub (ugh!) O tym samym adresie IP (WAN), na przykład w /etc/hosts:

your.wan.ip.address      servera serverb

a następnie sshwedług nazwy hosta i portu.

— Brandon Xavier
źródło

22

Istnieje kilka sposobów rozwiązania tego problemu:

Możesz wyłączyć sprawdzanie klucza hosta dla tego konkretnego hosta. W swoim ssh_configpliku ( ~/.ssh/config) umieść coś takiego:
```
Host remote.host.name
UserKnownHostsFile /dev/null
StrictHostkeyChecking no
```
Konfiguruje sshsię tak, aby nigdy nie przechowywać kluczy hosta remote.host.name, ale wadą jest to, że teraz jesteś otwarty na ataki typu man-in-the-middle (ponieważ ślepo akceptujesz klucze hosta, których nie wiesz, czy klucz zdalnego hosta się zmienił).
Możesz użyć podobnej techniki, aby po prostu nadać każdemu hostowi unikalny known_hostsplik:
```
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
```
Następnie połączysz się z tymi hostami przy pomocy ssh hostalub ssh hostb, i sshweźmiesz rzeczywistą nazwę hosta i port z pliku konfiguracji.

— Larsks
źródło

4

Nie, modyfikacja /etc/hostspliku również będzie działać. Podoba mi się to bardziej, ponieważ (a) nie wymaga eskalacji uprawnień i (b) oznacza, że nie musisz określać numerów portów w wierszu poleceń.

— larsks

1

W obu tych rozwiązaniach nadal konieczne będzie rozpoznawanie nazw (hosty lub DNS) w celu powiązania hosta i hosta z adresem IP WAN. Ale oba są doskonałymi sugestiami. Byłem zbyt leniwy, by pisać w LOL. Edycja: Właśnie zauważyłem tam nazwę hosta - podrap ją na temat rozpoznawania nazw.

— Brandon Xavier

2

@CopyRunStart: nie musisz określać portu w wierszu poleceń, ponieważ jest on już określony w twoim ~/.ssh/config(innym porcie dla każdego z nich hosta hostb), jak opisano w odpowiedzi Lariego. Podobnie można określić różne nazwy użytkownika, klucze, itp w tym pliku konfiguracyjnym dla różnych hostów więc wszystko co musisz zrobić, w wierszu polecenia jest ssh hostaalbossh hostb

— arielf

3

Gdybym mógł dwukrotnie głosować ~ / .ssh / config, zrobiłbym to. Skrzypanie w / etc / hosts z pewnością spowoduje inne problemy w trakcie rozwiązywania problemów.

— Aaron

1

Jest to znacznie lepsze rozwiązanie, IMO, niż modyfikowanie / etc / hosts. Jako drobną sprzeczkę wolałbym zastosować HostKeyAliasdyrektywę zamiast rozdzielać znane hosty na różne pliki. np.HostKeyAlias hosta

— crimson-egret

8

Nie mówisz, której wersji Solaris (i, co ważniejsze, SSH), której używasz, ale wystarczająco aktualne wersje OpenSSH rozwiązały ten problem.

Oto dwa wpisy z mojego known_hostspliku, które mają ten sam adres IP, ale różne numery portów (jeden to domyślny 22); jak widać przechowywane klucze nie są takie same.

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

Nie wiem, która wersja OpenSSH to wprowadziła, ale działam

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

— Szalony Kapelusznik
źródło

3

Aby rozwinąć mój komentarz do odpowiedzi na @larsks, myślę, że używanie ~/.ssh/configwpisów jest znacznie lepsze niż modyfikowanie / etc / hosts, chociaż wolałbym używać HostKeyAliasdzielenia znanych hostów na różne pliki. na przykład:

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

I podobnie dla hostb

— szkarłatna czapla
źródło