SSH in server NAT sullo stesso indirizzo IP pubblico

16

Sto provando a SSH dall'ufficio X ad alcune caselle Linux nell'ufficio Y. Le caselle Linux nell'ufficio Y sono dietro NAT e ognuna funziona sulle proprie porte. Posso raggiungerli tutti con successo tramite SSH, ma non riesco ad autenticarmi.

Sono stato in grado di SSH nella prima casella, ma quando sono arrivato alla seconda ha detto:

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

La mia comprensione è che si aspetta di vedere la stessa chiave da quell'indirizzo IP pubblico, ma ne vede uno diverso perché è un server SSH diverso.

Come posso ripararlo in modo che crei / accetti una chiave diversa da ciascun server dietro lo stesso indirizzo IP?

— Avvia esecuzione copia
fonte

1

+1 per nuvola disegnata a mano.

— Joe G

15

Il nome host o l'indirizzo IP viene archiviato come hash (o in testo normale in base alle opzioni e ai valori predefiniti della versione) nel known_hostsfile. La soluzione più semplice è aggiungere una voce per ciascun host al file DNS o /etc/hosts(ugh!) Con lo stesso indirizzo IP (WAN) come in /etc/hosts:

your.wan.ip.address      servera serverb

e quindi sshper nome host e porta.

— Brandon Xavier
fonte

22

Esistono alcuni modi per risolvere questo problema:

È possibile disabilitare il controllo della chiave host per questo host specifico. Nel tuo ssh_configfile ( ~/.ssh/config), inserisci qualcosa del tipo:
```
Host remote.host.name
UserKnownHostsFile /dev/null
StrictHostkeyChecking no
```
Questo si configura sshper non archiviare mai le chiavi host remote.host.name, ma il rovescio della medaglia è che ora sei aperto ad attacchi man-in-the-middle (perché stai accettando ciecamente le chiavi host non puoi dire se la chiave host remota è cambiata).
Puoi usare una tecnica simile per dare semplicemente a ciascun host un known_hostsfile univoco :
```
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
```
Quindi ti collegherai a questi host con ssh hostao ssh hostbe sshprenderai il nome host e la porta effettivi dal file di concigurazione.

— larsks
fonte

4

No, anche la modifica del /etc/hostsfile funzionerà. Mi piace di più perché (a) non richiede privilegi di escalation e (b) significa che non è necessario specificare i numeri di porta sulla riga di comando.

— Larks

1

La risoluzione dei nomi (host o DNS) sarà comunque richiesta in entrambe queste soluzioni per associare hosta e hostb all'indirizzo IP WAN. Ma entrambi sono ottimi suggerimenti che ero troppo pigro per digitare LOL Edit: ho appena notato il nome host lì dentro - grattalo sulla risoluzione dei nomi.

— Brandon Xavier,

2

@CopyRunStart: non è necessario specificare la porta sulla riga di comando perché è già stata specificata nella tua ~/.ssh/config(una porta diversa per ciascuna hosta hostb) come descritto nella risposta di Larsks. Allo stesso modo puoi specificare diversi nomi utente, chiavi, ecc. In questo file di configurazione per i diversi host, quindi tutto quello che devi fare sulla riga di comando è ssh hostaossh hostb

— ari

3

Se potessi votare due volte ~ / .ssh / config, lo farei. Giocherellare con / etc / hosts è destinato a causare altri problemi di risoluzione dei problemi lungo la strada.

— Aaron,

1

Questa è una soluzione molto migliore, IMO, che modificare / etc / hosts. Come piccolo cavillo, userei la HostKeyAliasdirettiva piuttosto che suddividere gli host conosciuti in file diversi. es.HostKeyAlias hosta

— cremisi-egretta,

8

Non dici quale versione di Solaris (e, soprattutto, SSH) stai usando, ma le versioni sufficientemente aggiornate di OpenSSH hanno risolto questo problema.

Qui ci sono due voci dal mio known_hostsfile, che hanno lo stesso indirizzo IP ma numeri di porta diversi (uno è il 22 implicito); come puoi vedere le chiavi memorizzate non sono le stesse.

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

Non so quale versione di OpenSSH abbia introdotto questo, ma sto correndo

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

— Cappellaio Matto
fonte

3

Per espandere il mio commento alla risposta di @larsks, penso che usare le ~/.ssh/configvoci sia molto meglio che modificare / etc / hosts, anche se userei HostKeyAliaspiuttosto che suddividere gli host conosciuti in file diversi. per esempio:

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

E allo stesso modo per hostb

— crimson-garzetta
fonte