Проблемы с проверкой ключа хоста SSH при использовании VIP

У нас есть 2 производственных сервера на VIP, только один используется одновременно, например:

myservice.mycompany.uk обычно указывает на server1, в случае сбоя server1 это означает, что он указывает на server2.

Есть некоторые другие серверы, которым нужно отправлять файлы на myservice.mycompany.uk через SFTP, и они должны быть полностью прозрачными для них, если мы перейдем на сервер2.

Проблема заключается в том, что, хотя ключи установлены как на сервере1, так и на сервере2, на других серверах возникают проблемы с проверкой ключа хоста, поскольку ключ хоста сервера2 отличается от ключа хоста сервера1. Это вызывает ошибку безопасности (так как строгая проверка включена), и строка должна быть удалена из known_hosts, чтобы это работало.

Наш ИТ-специалист предложил создать 2 записи в known_hosts, одну с ключом для server1 и одну с server2, обе с хостом myservice.mycompany.uk.

Это может сработать? Как это можно сделать с помощью putty / psftp на windows? Поскольку ключ хоста хранится в реестре, дублирующиеся имена не допускаются. Есть ли лучший способ, например, заставить серверы иметь один и тот же ключ хоста?

ssh cluster sftp

— Пол Криси
источник

Ответы:

Чтобы было проще для клиентов, я бы просто использовал один и тот же ключ хоста на обеих машинах. Просто скопируйте один из ключей (тот, который используется в данный момент) на второй компьютер. Они ключи в /etc/ssh/ssh_host_*.

Другой вариант - отключить проверку ключей хоста на клиентах. Это можно сделать, настроив их ssh_configна использование:

Host myservice.mycompany.uk
    StrictHostKeyChecking

— ℝaphink
источник

Отключение проверки ключа хоста, скорее, подрывает смысл использования SSH для передачи этих файлов, поэтому дублирование ключа хоста, вероятно, является лучшим решением.

— Джеймс Йель

Отключение проверки ключа хоста не означает, что связь не зашифрована должным образом, что является основным аспектом SSH. Тем не менее, как я уже сказал, я предпочитаю первое решение сам.

— ℝaphink

В клиентской версии (с разными серверными ключами) решения также необходимо добавить, UserKnownHostsFile=/dev/nullиначе первый ключ попадет в известные хосты, а второй приведет к предупреждению «человек посередине».

— Нильс

@ Nils это не обязательно; установка StrictHostKeyChecking yesсделает файл UserKnownHosts игнорируемым в пользу системного файла hosts. Так что все, что изменяет UserKnownHosts, довольно бессмысленно.

— Майкл Лоуман

Хорошо, я должен уточнить это далее: я говорю о случае, когда у вас есть два разных ключа сервера. Там вы должны указать StrictHostKeyChecking noи дополнительно установить в UserKnownHostsFile/ dev / null. В этом случае все ключи хоста будут приняты (что делает этот уровень безопасности бесполезным, конечно).

— Нильс

Я заархивировал это таким образом, пользователь root запустил один скрипт в 23:00, который подключается к логическому IP-адресу кластера Linux, поэтому в случае сбоя IP-адреса мое изменение SSH отпечатка пальца

echo "StrictHostKeyChecking no" >> /root/.ssh/config 
echo "UserKnownHostsFile /dev/null" >> /root/.ssh/config

Таким образом, настройка только для root

— c4f4t0r
источник