ssh: подлинность хоста 'hostname' не может быть установлена

Когда я 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.

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

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

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

РЕДАКТИРОВАТЬ

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

Ссылка .

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

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

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

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

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

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

• убедитесь, что сценарий подключается впервые по безопасному каналу
• проверка журналов или known_hosts для проверки отпечатков пальцев вручную (делается только один раз)

Чтобы отключить (или контролировать отключение), добавьте следующие строки в начало /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.

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

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

ssh -o BatchMode=yes -o StrictHostKeyChecking=no user@server.example.com "uptime"

Отредактируйте ваш файл конфигурации, обычно расположенный в «~ / .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.

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

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

Это просто отображается один раз.

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

Failed to add the host to the list of known hosts 

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

sudo chown -v $USER ~/.ssh/known_hosts

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

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"

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

В идеале вы должны создать центр сертификации с самостоятельным управлением. Начнем с создания пары ключей: ssh-keygen -f cert_signer

Затем подпишите открытый ключ хоста каждого сервера: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Это создает подписанный открытый ключ хоста: /etc/ssh/ssh_host_rsa_key-cert.pub

В /etc/ssh/sshd_config, укажите на HostCertificateэтот файл: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Перезапустите службу sshd: service sshd restart

Затем на клиенте SSH добавьте следующее ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

Выше содержится:

• @cert-authority
• Домен *.example.com
• Полное содержание открытого ключа cert_signer.pub

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

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

Для более подробной информации, смотрите эту вики-страницу .

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

Добавьте их в ваш / etc / ssh / ssh_config

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Запустите это на хост-сервере, это проблема предвидения

chmod -R 700 ~/.ssh

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

Я решаю проблему, которая дает следующую письменную ошибку:
Ошибка:
невозможно установить подлинность хоста «XXX.XXX.XXX».
Отпечаток ключа RSA - 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89.

Решение:
1. Установите любой инструмент openSSH.
2. запустите команду ssh
3. она попросит добавить этот хост как. принять ДА.
4. Этот хост будет добавлен в список известных хостов.
5. Теперь вы можете подключиться к этому хосту.

Это решение работает сейчас ......