Вы можете написать простой скрипт оболочки, который на лету сгенерирует пользовательский известный хост-файл, и при необходимости подключится к хосту.
См. Ssh: в командной строке укажите отпечаток ключа хоста сервера .
Есть ли способ я могу держать строгий хост - ключ проверки поведения на но она проверяет только отпечаток ключа сервера (который фактически уже уникальный идентификатор для хоста), без него также рассматривает имя хоста / IP?
У меня есть несколько личных мобильных / роуминговых устройств: телефоны, ноутбуки, другие телефоны, используемые в качестве карманных компьютеров и т. Д., И я обычно использую SSH между ними, используя IP-адрес, а не имя хоста.
Каждый раз, когда я оказываюсь в новой сети (обычно чей-то дом / офис / публичный WiFi) или срок аренды DHCP истекает в существующей сети, IP-адреса этих устройств перемешиваются, вызывая одну или обе из следующих ситуаций:
Же хост с неизменным ключом хоста находится в другом месте - так ssh
подсказывает мне, чтобы подтвердить тот же хост - ключ снова для нового IP.
Новый хост оказывается на том же IP-адресе, что и ранее подключенный к хосту (но предыдущий хост также все еще жив, только что с другим IP-адресом), поэтому при попытке подключиться к новому хосту ssh
он воспринимается как общеизвестная ошибка, предотвращает подключение, и для решения этой проблемы мне необходимо либо управлять несколькими известными файлами хостов с помощью параметров конфигурации, либо потерять известную связь ключей хоста для предыдущего хоста.
Я хотел бы сохранить способ автоматической проверки ключа хоста, но в моем сценарии использования бессмысленно связывать имя хоста / IP с самим сервером, чтобы:
Тот же ключ хоста, отображаемый для другого имени / IP, должен автоматически приниматься как известный хост.
Другой ключ хоста с ранее известным 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-адрес имени хоста и только проверять ключ из коробки.
Вы можете написать простой скрипт оболочки, который на лету сгенерирует пользовательский известный хост-файл, и при необходимости подключится к хосту.
См. Ssh: в командной строке укажите отпечаток ключа хоста сервера .
Вручную измените или добавьте известные записи хоста для каждого ключа хоста с полем имени / IP, установленным в *
.
Оказывается, есть две малоизвестные детали известного формата файлов хоста OpenSSH (задокументированные по какой-то причине на sshd
странице руководства вместо ssh
страницы руководства в разделе SSH_KNOWN_HOSTS_FILE_FORMAT ), которая дает именно то поведение, которое мне нужно:
OpenSSH позволяет использовать подстановочные знаки в поле имени хоста / IP, чтобы несколько (или даже все) хосты соответствовали заданному открытому ключу.
OpenSSH допускает более одной известной записи хоста для одного хоста и проверяет все из них, так что несколько ключей хоста могут считаться действительными для одного хоста.
Комбинируя эти две вещи, вы можете добавить любое количество ключей хоста, которые считаются действительными для любого хоста, к которому вы подключаетесь, и в то же время использовать строгую проверку ключа хоста.
Это работает независимо от того, HashKnownHosts
включен вы или нет - если вы изменяете существующую хешированную запись, вы все равно просто заменяете первое (разделенное пробелами) поле в записи. Если вы бежите ssh-keygen -H
вы делаете получить предупреждение, что шаблонные записи не могут быть хэшированными, но это нормально: весь смысл этого хеширования скрывает, что принимает подключения в случае содержимом файла подвергается, но *
подстановочный так же не раскрывают конкретные хосты ,
Я был неправ в своем вопросе, чтобы сказать, что нет никакой потери безопасности вообще. Существует небольшой, но реальный дополнительный риск: если один или несколько ключей хоста считаются действительными для нескольких хостов, то, если какой-либо из этих ключей хоста скомпрометирован, все ваши соединения могут быть скомпрометированы с помощью скомпрометированного ключа.
Для некоторых людей это будет приемлемый риск, стоящий за дополнительным удобством в обычном удобстве против компромисса безопасности.
Но с помощью небольшой дополнительной настройки это может быть уменьшено до довольно безболезненного уровня, если для каждого «роумингового» хоста будет установлен известный файл hosts, в котором будет храниться только запись ключа хоста с подстановочным знаком этого хоста, файл конфигурации для каждого из них, указывающих, что Известный файл hosts с UserKnownHosts
опцией file и указанием этого файла конфигурации с -F
опцией при подключении.