SSH nos servidores NAT no mesmo endereço IP público

16

Estou tentando fazer o SSH do escritório X para algumas caixas Linux no escritório Y. As caixas Linux no escritório Y estão atrás do NAT e cada uma delas é executada em suas próprias portas. Posso alcançar todos eles com êxito através do SSH, mas não consigo autenticar.

Consegui fazer o SSH na primeira caixa, mas quando cheguei na segunda, ele dizia:

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

Meu entendimento é que ele espera ver a mesma chave desse endereço IP público, mas está vendo uma diferente porque é um servidor SSH diferente.

Como posso corrigi-lo para que ele crie / aceite uma chave diferente de cada servidor atrás do mesmo endereço IP?

Digite a descrição da imagem aqui

linux ssh solaris ssh-keys Copiar Executar Iniciar
fonte
11
+1 para nuvem desenhada à mão.
JOEG

Respostas:

15

O nome do host ou o endereço IP está sendo armazenado como um hash (ou em texto sem formatação, dependendo das opções e padrões da versão) no seu known_hostsarquivo. A solução mais fácil é adicionar uma entrada para cada host no /etc/hostsarquivo DNS ou (ugh!) Com o mesmo endereço IP (WAN), como em /etc/hosts:

your.wan.ip.address      servera serverb

e depois sshpelo nome do host e porta.

Brandon Xavier
fonte
22

Existem algumas maneiras de corrigir isso:

  1. Você pode desativar a verificação de chave do host para esse host específico. No seu ssh_configarquivo ( ~/.ssh/config), coloque algo como:

    Host remote.host.name
UserKnownHostsFile /dev/null
StrictHostkeyChecking no

    Isso configura sshpara nunca armazenar chaves de host remote.host.name, mas a desvantagem é que agora você está aberto a ataques do tipo intermediário (porque você aceita cegamente as chaves do host, não pode saber se a chave do host remoto foi alterada).

  2. Você pode usar uma técnica semelhante para simplesmente fornecer a cada host um known_hostsarquivo exclusivo :

    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

    Você se conectará a esses hosts com ssh hostaou ssh hostb, e sshpegará o nome do host e a porta reais do arquivo de configuração.

larsks
fonte
4
Não, modificar o /etc/hostsarquivo também funcionará. Eu gosto mais disso porque (a) não requer privilégios escalados e (b) significa que você não precisa especificar números de porta na linha de comando.
Larsks
11
A resolução de nomes (hosts ou DNS) ainda será necessária em ambas as soluções para associar hosta e hostb ao endereço IP da WAN. Mas ambas são excelentes sugestões. Fiquei com preguiça de digitar LOL Edit: Acabei de notar o nome do host lá - arranhe isso sobre a resolução de nomes.
Brandon Xavier
2
@CopyRunStart: você não precisa especificar a porta na linha de comando porque ela já está especificada na sua ~/.ssh/config(uma porta diferente para cada uma hosta hostb), conforme descrito na resposta do Larsks. Da mesma forma, você pode especificar diferentes nomes de usuário, chaves, etc. neste arquivo de configuração para os diferentes hosts, para que tudo o que você tenha que fazer na linha de comando seja ssh hostaoussh hostb
#
3
Se eu pudesse votar novamente ~ / .ssh / config duas vezes, eu faria. Brincar com o / etc / hosts provavelmente causará outros problemas de solução de problemas no futuro.
Aaron
11
Esta é uma solução muito melhor, IMO, do que modificar o / etc / hosts. Como uma queixa menor, eu usaria a HostKeyAliasdiretiva em vez de dividir os hosts conhecidos em arquivos diferentes. por exemplo,HostKeyAlias hosta
carmesim-egret
8

Você não diz qual versão do Solaris (e, mais importante, SSH) está usando, mas versões suficientemente atualizadas do OpenSSH solucionaram esse problema.

Aqui estão duas entradas do meu known_hostsarquivo, que têm o mesmo endereço IP, mas números de porta diferentes (um é o implícito 22); como você pode ver, as chaves armazenadas não são as mesmas.

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

Não sei qual versão do OpenSSH introduziu isso, mas estou executando 

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

Para expandir meu comentário à resposta do @larsks, acho que usar ~/.ssh/configentradas é muito melhor do que modificar o / etc / hosts, embora eu usasse o HostKeyAliasinvés de dividir os hosts conhecidos em arquivos diferentes. por exemplo:

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

E da mesma forma para hostb

garça-vermelha
fonte