ssh: Невозможно установить подлинность хоста «имя хоста»

Question

Когда я схожу с машиной, когда-нибудь я получу это предупреждение об ошибке, и он попросит сказать «да» или «нет». Это вызывает некоторые проблемы при запуске из скриптов, которые автоматически передают 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. 

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

Answer 1

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

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

EDIT

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

Reference.

Answer 2

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

Answer 3

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

Answer 4

я решить проблему, которая дает ниже письменного ошибки:
Ошибка:
подлинность хозяина «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. Теперь вы можете связаться с этим хостом.

Это решение работает в настоящее время ......

Answer 5

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

Answer 6

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

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

Answer 7

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

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

включить следующую логику в сценарий:

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

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

Таким образом, вы подвержены Man-In-The-Ближний атаки только один раз, что может быть смягчено:

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

Answer 8

Редактировать файл конфигурация вашей обычно находятся в «~/.ssh/конфигурации», и на самом начале файла, добавьте следующие строки

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

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

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

Answer 9

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

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

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

Failed to add the host to the list of known hosts 

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

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

Answer 10

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

Answer 11

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

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

Answer 12

В идеале, вы должны создать самоуправляемый сертификатный. Начнем с генерации пары ключей: 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.

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

Для получения дополнительной информации см. this wiki page.