OpenSSH - есть ли способ сохранить строгую проверку ключа хоста, но проверять только ключ и игнорировать имя сервера?

482
mtraceur

Вопрос

Есть ли способ я могу держать строгий хост - ключ проверки поведения на но она проверяет только отпечаток ключа сервера (который фактически уже уникальный идентификатор для хоста), без него также рассматривает имя хоста / IP?

проблема

У меня есть несколько личных мобильных / роуминговых устройств: телефоны, ноутбуки, другие телефоны, используемые в качестве карманных компьютеров и т. Д., И я обычно использую SSH между ними, используя IP-адрес, а не имя хоста.

Каждый раз, когда я оказываюсь в новой сети (обычно чей-то дом / офис / публичный WiFi) или срок аренды DHCP истекает в существующей сети, IP-адреса этих устройств перемешиваются, вызывая одну или обе из следующих ситуаций:

  1. Же хост с неизменным ключом хоста находится в другом месте - так sshподсказывает мне, чтобы подтвердить тот же хост - ключ снова для нового IP.

  2. Новый хост оказывается на том же IP-адресе, что и ранее подключенный к хосту (но предыдущий хост также все еще жив, только что с другим IP-адресом), поэтому при попытке подключиться к новому хосту sshон воспринимается как общеизвестная ошибка, предотвращает подключение, и для решения этой проблемы мне необходимо либо управлять несколькими известными файлами хостов с помощью параметров конфигурации, либо потерять известную связь ключей хоста для предыдущего хоста.

Я хотел бы сохранить способ автоматической проверки ключа хоста, но в моем сценарии использования бессмысленно связывать имя хоста / IP с самим сервером, чтобы:

  1. Тот же ключ хоста, отображаемый для другого имени / IP, должен автоматически приниматься как известный хост.

  2. Другой ключ хоста с ранее известным IP-адресом должен просто вызвать диалог да / нет для нового ключа.

Другими словами, я хотел бы, known_hostsчтобы меня проверяли, как если бы это был просто список известных ключей, а не список кортежей известных имен (/ IP) <->.

Но безопасность

Просто опережая эту касательную:

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

Единственная разница в случае MitM заключается в том, что я получаю приглашение да / нет вместо упрывающего соединения, но точно так же я сразу узнаю, что что-то не так, так как я подключаюсь к устройству, чей ключ хоста Я ожидаю быть известным.

Комментарии к другим возможным идеям решения

DNS не применяется, так как мы говорим о переключении между различными сетями и часто частными IP-адресами в локальной сети и т. Д.

/etc/hosts твики были бы просто болью, учитывая, как часто я мог бы менять сети.

Я не использую технологии автоматического обнаружения / саморекламы, такие как mDNS / ZeroConf / Bonjour, потому что они добавляют немаловажную сложность настройки, обслуживания и аудита безопасности для некоторых из этих небольших устройств (на некоторых из них мне нужно скомпилировать все, что я хочу использовать из источника), а я просто вообще не фанат своих устройств, рекламирующих себя активно и постоянно в сети в целом.

Текущее нереалистичное решение, которое у меня есть, которое, по крайней мере, уменьшает known_hostsболь, состоит в том, чтобы заставить ssh использовать /dev/nullв качестве известного файла hosts - что означает, что мне просто предлагается каждый раз проверять ключ . Но даже с моей хорошей памятью и искусством работы с ключами ASCII это не масштабируется и не ломает автоматизацию, и мне это сходит с рук только потому, что количество играемых ключей пока очень мало.

Я мог бы пропатчить, sshчтобы позволить KeyOnlyвариант для строгой проверки ключа хоста вместо просто «да» и «нет», но я просто не знаю, есть ли у меня это прямо сейчас, тем более что это означало бы, что мне придется либо удастся объединить его вверх по течению или собрать релизы OpenSSH из исходного кода для еще большего количества устройств.

Я испытываю желание написать локальную службу, которая отслеживает известные ключи хоста sshи создает именованный сокет домена Unix, который sshзатем может использовать в качестве файла известных хостов вместо обычного простого текстового файла. Это кажется выполнимым, но требует некоторой осторожности, чтобы стать правильным и надежным.

Очевидно, что отключение строгой проверки ключа хоста не вариант. Если бы я собирался сделать это, я мог бы просто использовать, rshчтобы не притворяться, будто осталась какая-то безопасность. Мы не животные.

Поэтому я надеюсь, что есть какой-то умный способ просто сделать эту настройку поведения проверки ключей хоста OpenSSH, чтобы игнорировать IP-адрес имени хоста и только проверять ключ из коробки.

4

2 ответа на вопрос

1
Martin Prikryl

Вы можете написать простой скрипт оболочки, который на лету сгенерирует пользовательский известный хост-файл, и при необходимости подключится к хосту.

См. Ssh: в командной строке укажите отпечаток ключа хоста сервера .

Спасибо и +1! Я закончил тем, что нашел другое решение, которое подходит для варианта использования, о котором я спрашивал более прямо (подробности см. В моем собственном ответе), но если бы я этого не нашел, или если бы OpenSSH когда-либо убирал поддержку известных функций обработки файлов хостов, которые делают моя работа по решению, это было бы отличной отправной точкой для построения решения вопроса. mtraceur 5 лет назад 1
1
mtraceur

Решение

Вручную измените или добавьте известные записи хоста для каждого ключа хоста с полем имени / IP, установленным в * .

объяснение

Оказывается, есть две малоизвестные детали известного формата файлов хоста OpenSSH (задокументированные по какой-то причине на sshdстранице руководства вместо sshстраницы руководства в разделе SSH_KNOWN_HOSTS_FILE_FORMAT ), которая дает именно то поведение, которое мне нужно:

  1. OpenSSH позволяет использовать подстановочные знаки в поле имени хоста / IP, чтобы несколько (или даже все) хосты соответствовали заданному открытому ключу.

  2. OpenSSH допускает более одной известной записи хоста для одного хоста и проверяет все из них, так что несколько ключей хоста могут считаться действительными для одного хоста.

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

Это работает независимо от того, HashKnownHostsвключен вы или нет - если вы изменяете существующую хешированную запись, вы все равно просто заменяете первое (разделенное пробелами) поле в записи. Если вы бежите ssh-keygen -Hвы делаете получить предупреждение, что шаблонные записи не могут быть хэшированными, но это нормально: весь смысл этого хеширования скрывает, что принимает подключения в случае содержимом файла подвергается, но *подстановочный так же не раскрывают конкретные хосты ,

Предупреждение о безопасности

Я был неправ в своем вопросе, чтобы сказать, что нет никакой потери безопасности вообще. Существует небольшой, но реальный дополнительный риск: если один или несколько ключей хоста считаются действительными для нескольких хостов, то, если какой-либо из этих ключей хоста скомпрометирован, все ваши соединения могут быть скомпрометированы с помощью скомпрометированного ключа.

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

Но с помощью небольшой дополнительной настройки это может быть уменьшено до довольно безболезненного уровня, если для каждого «роумингового» хоста будет установлен известный файл hosts, в котором будет храниться только запись ключа хоста с подстановочным знаком этого хоста, файл конфигурации для каждого из них, указывающих, что Известный файл hosts с UserKnownHostsопцией file и указанием этого файла конфигурации с -Fопцией при подключении.

Похожие вопросы