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


29

Я регулярно подключаюсь к компьютеру с двойной загрузкой 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. Тем не менее, я все еще хочу получить предупреждение, если есть настоящая атака «человек посередине», т.е. если используется другой ключ, чем эти два.


Что вы хотите сделать? Редактировать это для чего?
Rhyuk

@Rhyuk: отредактируйте его, чтобы иметь возможность распознавать как действительный OSX, так и ключ хоста linux для IP-адреса, имени хоста и имени хоста.домен.
Фредерик Гроссханс

@Rhyuk: я редактировал этот вопрос. Это более понятно сейчас?
Фредерик Гроссханс

2
Вы просто подумали, чтобы обе установки имели один и тот же ключ?
Зоредаче

3
Есть несколько случаев, когда разумно использовать один IP-адрес для доступа к нескольким объектам (каждый с отдельными ключами хоста SSH) и при этом сохранять строгий контроль, что ТОЛЬКО эти ключи хоста видны клиенту SSH. Например, некоторые настройки высокой доступности, когда к кластеру блоков обращаются с использованием одного общего IP-адреса, но где (по какой-то причине) ключ хоста SSH, видимый клиентами, изменяется в зависимости от того, какой блок кластера активен в данный момент. Другой случай, когда несколько хостов SSH находятся за межсетевым экраном NAT и получают доступ извне, все они будут иметь одинаковый IP-адрес.
IllvilJa

Ответы:


12

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


Я бы предпочел клиентскую версию, но попробую, если не найду. Кстати, OSX (нестандартная) локализация файлов есть /private/etc/ssh_host*, нет /etc/ssh/ssh_host*.
Фредерик Гроссханс

Копирование файлов с одной машины на другую (две машины linux) у меня не сработало. Хотя содержимое файла было идентичным, хэш не был таким, я все еще получал проблему (может быть, время модификации?). Решение ниже намного лучше.
Став

sshdзагружает ключи хоста один раз при запуске, поэтому вам, скорее всего, потребуется перезагрузка sshd. Я добавлю это к ответу. Что касается других решений лучше, это зависит от вашей ситуации. Я бы сказал, что основные плюсы этого метода в том, что он требует единовременной настройки и с большей вероятностью будет работать с несколькими реализациями клиентов SSH.
Jjlin

Любопытно, что мой сравнительно недавний OpenSSH 7.4p1 sshdзагружает ключи хоста при каждом новом соединении. Может быть, так было долго, и я просто предположил, что ключи хоста были обработаны как другая sshdконфигурация. Так или иначе, это может или не может быть вашей проблемой.
Jjlin

Будет ли плохой идеей сделать это с двумя хостами в кластере, которые имеют один и тот же адрес VRRP? При отработке отказа хост, который отвечает, будет другим. Я хотел бы не получить предупреждение.
Colin 't Hart

26

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

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

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


4
На самом деле, если у вас есть клиент linux, вам даже не нужно удалять ошибочную строку, вам нужно только закомментировать ее с помощью хеша ('#') в начале. Затем, после того как вы приняли новый ключ, вы можете просто отредактировать файл known_hosts и раскомментировать строку со старым ключом. Но да, это было бы полезно и в Putty.
IllvilJa

1
Если есть два хоста с одинаковым именем, но разными IP-адресами и разными ключами хоста, этот обходной путь также работает: закомментируйте (или временно удалите) тогда обе строки для этого хоста (одну на основе IP-адреса и одну на основе хоста). name), подключитесь к неизвестному хосту, а затем заново добавьте строки, которые были закомментированы или удалены.
Кай Петцке

13

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

Источник: /programming/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

Я видел эту статью, но она не соответствует моему случаю: два сервера различаются по номеру порта в статье, а не в моем случае. Кроме того, я хотел бы сохранить дополнительные уровни безопасности, вносимые солеными хэшами, в known_hostsи CheckHostIP.
Фредерик Гроссханс

1
@ FrédéricGrosshans, я проверяю проверено. Вам не нужно иметь отдельные порты, и опция HashKnownHosts прекрасно работает с HostKeyAlias.
Зоредаче

Обратной стороной этого, если я не ошибаюсь, является то, что он настраивается для каждого клиента, а принятый ответ настраивается только на принимающих серверах ssh.
FreeSoftwareServers

2

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


На самом деле, IP-адрес не 192.168.0.xxявляется и не является частным. Это «настоящий» адрес IPv4, данный моим университетом, который я не могу изменить.
Фредерик Гроссханс

Если вы свяжетесь с Википедией , вы увидите 192.168.0.0 - 192.168.255.255 (ваш вопрос, указанный как 192.168.0.9, который попадает в этот диапазон) относится к "частным адресным пространствам IPv4". Таким образом, под «частным» я ссылался не на то, что вы «владеете» им, а на технические характеристики IETF . В своем вопросе вы не указали, что не можете сменить IP, извините - но с учетом предоставленных данных мой ответ был подходящим.
Иззи

Извините за плохо сформулированный вопрос. Я не понизил.
Фредерик Гроссханс

Никаких проблем, и tnx за то, что дал мне знать - делает понижающий голос менее обескураживающим. Но другая идея: я не уверен, откуда файл known_hosts берет имя хоста, обратный DNS или предложенный клиентом. Вы можете попробовать переименовать один из ваших «хостов», чтобы он представлял другое имя хоста. Или добавьте оба ключа хоста: ssh сообщает вам «обидную строку» в вашем файле known_hosts (когда # 1 содержится и вы соединяетесь с # 2). Таким образом, вы можете скопировать эту строку в другой файл, удалить ее из known_hosts, разрешить соединению # 2 и добавить его строку, а также добавить удаленную строку обратно. Не уверен, что это работает, но вы можете попробовать.
Иззи

2

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

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


Привет @Pyheme, добро пожаловать в Super User! Обратите внимание, что этому вопросу почти 4 года. Нет ничего плохого в том, чтобы ответить на него, но имейте в виду, что возможно, вы не получите ответ.
Hewbot

У меня больше нет машины с OS X, но ваш ответ может быть полезен для кого-то еще. В этом весь смысл обмена стека
Фредерик Гроссханс,

@ Hewbot ... действительно, теперь я это вижу. Не знаю почему, это появилось в списке недавних вопросов ...
Pyheme

1

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

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


Эта статья о запрещении проверки ключей. Я хочу сохранить проверку ключа, и я не хочу запрещать его каждый раз, когда hostnameон перезагружается в Linut или OSX
Frédéric Grosshans

1
Добро пожаловать в Супер пользователя! Хотя это может теоретически ответить на вопрос, было бы предпочтительным включить здесь основные части ответа и предоставить ссылку для справки. Я включил короткую часть, но это может быть не то, что вы намеревались ...
Тамара Вийсман

1

Поскольку вы хотите сохранить строгую проверку ключа хоста, я бы попросил их использовать разные 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и приняв новый ключ, затем убрав эту запись.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.