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

Question

Вопрос

Есть ли способ я могу держать строгий хост - ключ проверки поведения на но она проверяет только отпечаток ключа сервера (который фактически уже уникальный идентификатор для хоста), без него также рассматривает имя хоста /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 , как файл известных хостов - что означает , что я просто получить приглашение проверить ключ каждый раз. Но даже с моей хорошей памятью и искусством работы с ключами ASCII это не масштабируется и не ломает автоматизацию, и мне это сходит с рук только потому, что количество играемых ключей пока очень мало.

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

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

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

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

Answer 1

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

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

Answer 2

По-другому

Хотя решение использования подстановочного знака в KnownHosts является хорошим, здесь есть дополнительное решение, которое не требует ручного редактирования файла known_hosts каждом добавлении другого устройства.

Поместите это в ваш ~/.ssh/config:

# mDNS Example: `ssh myphone.local`
# Write link-local hostnames, not DHCP dynamic IPs, to known_hosts. 
Host *.local
     CheckHostIP no

Это проверяет HostKey на основе только имени хоста для устройств в локальной сети, а не IP-адреса. Это предполагает, что у вас запущен Multicast DNS (mDNS). Устройство с именем хоста "argylegargoyle" будет доступно при запуске ssh argylegargoyle.local .

Зачем?

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

Я предлагаю RFC 6762 локальные имена ссылок, потому что они чрезвычайно удобны, решают проблему, и многие люди имеют их в наличии, даже на небольших устройствах. Более того, в ситуации, описанной первоначальным спрашивающим, когда многие мобильные устройства часто перемещаются между различными сетями, может быть сложно найти новый IP-адрес каждого устройства. Многоадресный DNS решает проблему, так как вы всегда можете использовать ssh mytoaster.local независимо от его IP-адреса.

В чем подвох?

Гоча является то , что, как было упомянуто в вопросе, вы должны иметь MDNS , работающие на устройствах. Так как многие системы поставляются с уже установленным, стоит попробовать ssh myhostname.local чтобы посмотреть, работает ли он. Если это так, отлично! Больше ничего не нужно делать.

Включение mDNS

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

• Debian GNU/Linux, Ubuntu, Mint, Raspberry Pi: apt install avahi-daemon
• Продукты Apple (iPhone, Mac) всегда включены по умолчанию.
• Microsoft реализует mDNS, но пользователи Windows могут просто установить Bonjour от Apple.
• Android: должен работать из коробки, но зависит от приложения.
• LEDE/OpenWRT (очень маленькие устройства, такие как WiFi-маршрутизаторы, роботы Arduino): opkg install umdns или opkg install avahi-daemon .

Answer 3

Решение

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

объяснение

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

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

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

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

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

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

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

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

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