ssh: подлинность хоста 'hostname' не может быть установлена - PullRequest
140 голосов
/ 08 сентября 2010

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

Предупреждение:

The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is    SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.

Есть ли способ автоматически сказать "да" или игнорировать это?

Ответы [ 14 ]

117 голосов
/ 08 сентября 2010

В зависимости от вашего ssh-клиента вы можете установить для параметра StrictHostKeyChecking значение no в командной строке и / или отправить ключ в нулевой файл known_hosts. Вы также можете установить эти параметры в своем конфигурационном файле, либо для всех хостов, либо для заданного набора IP-адресов или имен хостов.

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

EDIT

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

Reference .

68 голосов
/ 29 июля 2014

Старый вопрос, который заслуживает лучшего ответа.

Вы можете запретить интерактивное приглашение, не отключая StrictHostKeyChecking (что небезопасно).

Включите следующую логику в ваш скрипт:

if [ -z `ssh-keygen -F $IP` ]; then
  ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi

Проверяет, находится ли открытый ключ сервера в known_hosts.Если нет, он запрашивает открытый ключ с сервера и добавляет его к known_hosts.

Таким образом, вы подвергаетесь атаке «Человек посередине» только один раз, что может быть смягчено с помощью:

  • , гарантирующего, что сценарий впервые подключается по безопасному каналу
  • проверка журналов или известных_хостов для проверки отпечатков пальцев вручную (выполняется только один раз)
34 голосов
/ 23 августа 2013

Чтобы отключить (или управлять отключением), добавьте следующие строки в начало /etc/ssh/ssh_config ...

Host 192.168.0.*
   StrictHostKeyChecking=no
   UserKnownHostsFile=/dev/null

Параметры:

  • Подсеть хоста может быть *, чтобы разрешить неограниченный доступ ко всем IP-адресам.
  • Редактировать /etc/ssh/ssh_config для глобальной конфигурации или ~/.ssh/config для пользовательской конфигурации.

См. http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

Аналогичный вопрос на superuser.com - см. https://superuser.com/a/628801/55163

15 голосов
/ 18 февраля 2014

Убедитесь, что ~/.ssh/known_hosts доступно для записи.Это исправило это для меня.

12 голосов
/ 18 июня 2014

Лучший способ добиться этого - использовать BatchMode в дополнение к StrictHostKeyChecking.Таким образом, ваш скрипт примет новое имя хоста и запишет его в файл known_hosts, но не потребует вмешательства да / нет.

ssh -o BatchMode=yes -o StrictHostKeyChecking=no user@server.example.com "uptime"
10 голосов
/ 17 ноября 2014

Отредактируйте ваш файл конфигурации, обычно расположенный в '~ / .ssh / config', и в начале файла добавьте следующие строки

Host *
    User                   your_login_user
    StrictHostKeyChecking  no
    IdentityFile          ~/my_path/id_rsa.pub

Пользователь, установленный на your_login_user, говорит, что эти настройкипринадлежит your_login_user
StrictHostKeyChecking, установленный в no, исключает приглашение
IdentityFile - путь к ключу RSA

Это работает для меня и моих сценариев, удачи вам.

6 голосов
/ 27 мая 2015

Это предупреждение выдается из-за функций безопасности, не отключайте эту функцию.

Он отображается только один раз.

Если он все еще появляется после второго подключения, проблема, вероятно, заключается в записи в файл known_hosts. В этом случае вы также получите следующее сообщение:

Failed to add the host to the list of known hosts 

Вы можете исправить это, сменив владельца, изменив права доступа к файлу для записи пользователем.

sudo chown -v $USER ~/.ssh/known_hosts
4 голосов
/ 02 августа 2016

Со ссылкой на ответ Кори, я изменил его и использовал нижеприведенную команду, которая работает.Без exit оставшаяся команда фактически выполняла вход на удаленную машину, чего я не хотел в сценарии

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"
3 голосов
/ 27 января 2016

Сделай это -> chmod +w ~/.ssh/known_hosts.Это добавляет разрешение на запись в файл на ~/.ssh/known_hosts.После этого удаленный хост будет добавлен в файл known_hosts при следующем подключении.

2 голосов
/ 05 февраля 2013

Обычно эта проблема возникает, когда вы очень часто меняете ключи. В зависимости от сервера может потребоваться некоторое время для обновления нового ключа, который вы создали и вставили на сервер. Поэтому после генерации ключа и вставки на сервер подождите от 3 до 4 часов, а затем попробуйте. Проблема должна быть решена. Это случилось со мной.

...