Как отредактировать known_hosts, когда несколько хостов имеют одинаковый IP и DNS имя?

Question

Я регулярно подключаюсь к компьютеру с двойной загрузкой OS X / Linux. Экземпляры двух ОС не используют один и тот же ключ хоста, поэтому их можно рассматривать как два хоста с одинаковыми IP и DNS. Допустим, IP-адрес 192.168.0.9 , а имена являются hostname и hostname.domainname

Насколько я понял, решение для возможности подключения к двум хостам заключается в добавлении их обоих в файл ~/.ssh/know_hosts . Однако это легче сказать, чем сделать, потому что файл хешируется и имеет, вероятно, несколько записей на хост (192.168.0.9 , hostname , hostname.domainname). Как следствие, у меня есть следующее предупреждение

Warning: the ECDSA host key for 'hostname' differs from the key for the IP address '192.168.0.9'

Есть ли простой способ отредактировать файл known_hosts , сохранив при этом хэши. Например, как я могу найти строки, соответствующие данному хостам? Как я могу сгенерировать хеши для некоторых известных хостов?

Идеальное решение позволило бы мне беспрепятственно подключаться к этому компьютеру с помощью ssh, независимо от того, назову ли я его 192.168.0.9 , hostname или hostname.domainname , а также если он использует свой Linux hostkey или OSX hostkey. Тем не менее, я все еще хочу получить предупреждение, если есть настоящая атака «человек посередине», то есть если используется другой ключ, чем эти два.

Answer 1

Как предложил @Izzy в приведенном выше комментарии, ssh сообщает вам обидную строку, и, удалив эту строку (сохранив ее в другом месте), приняв новый ключ и затем скопировав удаленную строку обратно, вы получите два ключа для одного и того же хост, и ssh примет либо.

(Вы также можете использовать ssh-keygen -H -F <hostname> чтобы найти строки в вашем файле known_hosts, которые соответствуют этому имени хоста. Выполнение этого после копирования удаленной строки должно привести к появлению двух записей.)

Если кто-нибудь знает, как заставить PuTTY делать то же самое, мне было бы очень интересно узнать об этом.

Answer 2

Самое простое решение здесь - просто использовать одни и те же ключи хоста для Linux и OS X. То есть выбрать один набор файлов /etc/ssh/ssh_host_*_key* и скопировать их в другую ОС. Тогда тот же ключ хоста будет представлен клиенту SSH независимо от того, в какую ОС вы загрузились, и клиент SSH не будет мудрее.

Answer 3

Я нашел это, которое может помочь вам с тем, чего вы хотите достичь.

Источник: https://stackoverflow.com/questions/733753/how-to-handle-ssh-host-key-verification-with-2-different-hosts-on-the-same-but

Создайте файл конфигурации в вашем каталоге .ssh следующим образом:

Host server1
  Hostname x1.example.com
  HostKeyAlias server1
  CheckHostIP no
  Port 22001
  User karl

Host server2
  Hostname x2.example.com
  HostKeyAlias server2
  CheckHostIP no
  Port 22002
  User karl

Объяснение ниже (от man ssh_config)

CheckHostIP

Если для этого флага установлено значение "да", ssh (1) дополнительно проверит IP-адрес хоста в файле known_hosts. Это позволяет ssh определять, изменился ли ключ хоста из-за подмены DNS. Если для параметра установлено значение "нет", проверка не будет выполнена. По умолчанию "да".

HostKeyAlias

Задает псевдоним, который следует использовать вместо реального имени хоста при поиске или сохранении ключа хоста в файлах базы данных ключей хоста. Эта опция полезна для туннелирования соединений SSH или для нескольких серверов, работающих на одном хосте.

В строке "Имя пользователя и порт" вам также не нужно указывать эти параметры в командной строке, поэтому вы можете просто использовать:

% ssh server1
% ssh server2

Answer 4

Я не сталкиваюсь с этой проблемой при подключении к различным блокам VPS, использующим один и тот же IP-адрес, поскольку у каждого из них есть свой порт SSH (2002, 2322 и т.д.), Поэтому они регистрируются как известные хосты с разными ключами.

Может ли это быть обходным путем для вас?

Answer 5

Самый простой способ решить вашу проблему - дать каждому хосту свой собственный IP-адрес. С 253 адресами, доступными в вашей (частной) сети и IPv4, это не должно быть проблемой. Дайте им фиксированные IP-адреса (так как DHCP-сервер будет идентифицировать машину на основе MAC-адреса сетевых карт, и оба получат один и тот же адрес). Я не вижу другого решения, если вы хотите сохранить меры безопасности (которые я бы тоже не отказался от этого небольшого "комфорта").

Answer 6

Поскольку вы хотите сохранить строгую проверку ключа хоста, я бы попросил их использовать разные файлы known_hosts . Чтобы сделать это, настройте файл ~/.ssh/config (или файл /etc/ssh/ssh_config если вам это нужно для работы с несколькими учетными записями локальных пользователей) следующим образом:

Host myserver.osx
  UserKnownHostsFile ~/.ssh/known_hosts.dual.osx
  # default is ~/.ssh/known_hosts
  Hostname $REALHOSTNAME

Host myserver.linux
  UserKnownHostsFile ~/.ssh/known_hosts.dual.linux
  Hostname $REALHOSTNAME

заменяя $REALHOSTNAME на фактическое имя хоста или IP-адрес, конечно. (Неважно, какой вы выберете, если вы выберете что-то после "Hostname", которое будет соответствовать IP-адресу, но я бы использовал имя хоста вместо IP-адреса, просто на общих принципах.)

Тогда ssh myserver.linux и ssh myserver.osx могут иметь разные ключи хоста, но вы все равно получаете проверку. Если работает Linux и вы вводите OS X (или наоборот), вы получите предупреждение (которое, я считаю, является желаемым эффектом).

Если бы у меня была эта проблема, я бы удостоверился, что в главном файле known_hosts что-то совершенно не так, что не соответствует ни одному из них, так что если вы $REALHOSTNAME вместо myserver.osx вы получите предупреждение. :-) Я бы сделал это, поставив что-то вроде

<ip-address-of-github.com> $REALHOSTNAME

в моем /etc/hosts , затем выполните команду ssh $REALHOSTNAME и примите новый ключ, а затем удалите эту запись.

Answer 7

Еще одна статья, в которой описано несколько способов решения вашей проблемы:

Второй метод использует два параметра openSSH : StrictHostKeyCheckin и UserKnownHostsFile . Этот метод обманывает SSH, настраивая его для использования пустого файла known_hosts и НЕ запрашивая подтверждение ключа идентификации удаленного хоста.