Подача входных данных в / dev / tty для продолжения работы ssh
После некоторых экспериментов я обнаружил, что можно использовать следующую команду:
ip monitor
Будет отображаться список происходящего. Запустите его в одном терминале, перезапустите сетевой интерфейс в другом, и вы увидите строку, напечатанную, когда каждый IP-адрес будет удален, а затем снова добавлен.
Он до сих пор не объясняет, откуда именно исходит IP, но он сказал мне, что это был ra (Объявление маршрутизатора), который позволил мне взглянуть на конфигурацию моего маршрутизатора.
В моем случае я рекламировал тот же префикс fdaa :: / 64 , который я назначил как статический IP-адрес (предполагая, что статический IP-адрес в этой подсети не позволит назначить динамический), но вместо этого Я получил как статический, так и динамический IP-адрес в той же подсети , что вызвало проблемы. Я все еще не понимаю, является ли это ошибкой.
После долгих раздумий я изменил маршрутизатор, чтобы объявить другой префикс (на самом деле другая подсеть в том же ULA / 48 , поэтому fdaa: 0: 0: 1/64 ]), потому что таким образом обе подсети соответствуют одному и тому же назначению ULA, но, будучи разными подсетями, они не заставляют машину отвечать с неправильного IP-адреса, если у нее есть IP-адреса, принадлежащие обеим подсетям.
Я избежал этой проблемы при работе со встроенными системами, которые часто переустанавливались (тем самым генерируя новые ключи хоста). Если вы хотите слепо принять новый ключ хоста, вы можете это сделать, но имейте в виду, что это устраняет любую защиту от выдачи себя за другую сторону. Это может подойти для действий с низким риском в хорошо контролируемой сети, но не рекомендуется для использования в публичном Интернете!
Для рассматриваемых хостов сделайте ssh write автопринятием нового ключа хоста, но запишите его в /dev/null:
Host h
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no
Похоже, для SSH нет возможности никогда не проверять known_hosts.
Если проблема в вопросе заключается в том, что ключи хостов никогда не были известны этому клиенту (в отличие от известных, но теперь измененных), то достаточно добавить -o StrictHostKeyChecking=no в командную строку SSH.
Повторяю, делайте это, только если вы принимаете снижение безопасности. Я предполагаю, что да, поскольку вы говорите, что хотите безоговорочно отвечать да на интерактивный SSH.
Запись в / dev / tty не учитывает идентификатор процесса; у вас ничего не получится.
Хотя это одно и то же устройство , существуют разные файловые дескрипторы, которые процесс будет открывать на данном устройстве. В Linux вы можете управлять отдельными файловыми дескрипторами, если знаете идентификатор процесса, т. Е. / proc / PID / fd / 0 является стандартным вводом для процесса, идентификатор которого PID .
В вашем случае программа открывает устройство, и его файловый дескриптор также находится в / proc / PID / fd (но не так хорошо идентифицирован). Приложение могло «видеть» информацию о символической ссылке из этого каталога и манипулировать ею.
Если вы присмотритесь, все элементы в / proc / PID / fd имеют разные значения inode (потому что это разные файловые дескрипторы). Отображение записи в proc / PID / fd означает, что вы выполняете вывод для этого файлового дескриптора.
Но ssh не ожидает ввода с этого направления, не имеет возможности для дополнительных запросов - обходной путь, который вы используете, вероятно, лучшее, что вы можете сделать.