SSH на серверы NAT с одинаковым публичным IP-адресом

16

Я пытаюсь перевести SSH из офиса X в несколько блоков Linux в офисе Y. Блоки Linux в офисе Y находятся за NAT, и каждый работает на своих собственных портах. Я могу успешно связаться со всеми из них через SSH, но не могу пройти проверку подлинности.

Я был в состоянии SSH в первую коробку, но когда я добрался до второй, он сказал:

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

Насколько я понимаю, он ожидает увидеть тот же ключ с этого публичного IP-адреса, но видит другой, потому что это другой SSH-сервер.

Как я могу это исправить, чтобы он создавал / принимал разные ключи от каждого сервера за тем же IP-адресом?

— Копировать Run Start
источник

1

+1 за нарисованное от руки облако.

— JoeG

15

Имя хоста или IP-адрес хранится в вашем known_hostsфайле в виде хэша (или в виде простого текста в зависимости от параметров и версии по умолчанию) . Самый простой обходной путь - добавить запись для каждого хоста в DNS или /etc/hosts(тьфу!) Файл с тем же IP-адресом (WAN), как в /etc/hosts:

your.wan.ip.address      servera serverb

а затем sshпо имени хоста и порту.

— Брэндон Ксавье
источник

22

Есть несколько способов исправить это:

Вы можете отключить проверку ключа хоста для этого конкретного хоста. В вашем ssh_configфайле ( ~/.ssh/config) поместите что-то вроде:
```
Host remote.host.name
UserKnownHostsFile /dev/null
StrictHostkeyChecking no
```
Это sshпозволяет никогда не хранить ключи хоста remote.host.name, но недостатком является то, что теперь вы открыты для атак «человек посередине» (поскольку вы слепо принимаете ключи хоста, вы не можете сказать, изменился ли ключ удаленного хоста).
Вы можете использовать похожую технику, чтобы просто дать каждому хосту уникальный known_hostsфайл:
```
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
```
Затем вы подключитесь к этим хостам с помощью ssh hostaили ssh hostbи sshполучите фактическое имя хоста и порт из файла конфигурации.

— larsks
источник

4

Нет, изменение /etc/hostsфайла также будет работать. Мне это нравится больше, потому что (а) он не требует повышения привилегий и (б) это означает, что вам не нужно указывать номера портов в командной строке.

— Жаворонки

1

Разрешение имен (хосты или DNS) все еще потребуется в обоих этих решениях, чтобы связать hosta и hostb с IP-адресом WAN. Но оба являются отличными предложениями, которые мне было лень набирать в LOL Edit: Просто заметил там имя хоста - поцарапайте про разрешение имен.

— Брэндон Ксавье

2

@CopyRunStart: вам не нужно указывать порт в командной строке, потому что он уже указан в вашем ~/.ssh/config(другой порт для каждого hosta hostb), как описано в ответе larsks. Точно так же вы можете указать разные имена пользователей, ключи и т. Д. В этом конфигурационном файле для разных хостов, поэтому все, что вам нужно сделать в командной строке, - ssh hostaилиssh hostb

— arielf

3

Если бы я мог дважды поднять ~ / .ssh / config, я бы сделал это. Работа с / etc / hosts неизбежно вызовет другие проблемы с устранением неполадок в будущем.

— Аарон

1

Это намного лучшее решение, IMO, чем изменение / etc / hosts. В качестве незначительного клеветы я бы использовалHostKeyAlias директиву, а не разделял известные хосты на разные файлы. напр.HostKeyAlias hosta

— малиновый цапля

8

Вы не говорите, какую версию Solaris (и, что более важно, SSH) вы используете, но достаточно современные версии OpenSSH решили эту проблему.

Вот две записи из моего known_hostsфайла, которые имеют один и тот же IP-адрес, но разные номера портов (одна - неявная 22); как вы видите сохраненные ключи не совпадают.

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

Я не знаю, какая версия OpenSSH представила это, но я бегу

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

— Безумный Шляпник
источник

3

Чтобы расширить мой комментарий к ответу @larsks, я думаю, используя ~/.ssh/config записи гораздо лучше, чем модифицировать / etc / hosts, хотя я бы использовал HostKeyAliasвместо того, известные хосты на разные файлы. например:

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

И аналогично для hostb

— малиново-цапля
источник