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


153

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

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


27
Я бы посоветовал против этого. Вам нужно разобраться, почему вы получаете эти ошибки, иначе вы открываете себя посреднику, от которого эти ошибки пытаются вас защитить.
Питер Багналл

3
Это может быть вызвано изменением сервера с использованием этого ключа ssh, или это может быть вызвано тем, что кто-то сидит между вами и сервером и слушает все, что вы отправляете / получаете.
Дерекдрееры

в чем может быть причина этой ошибки?
19

Я не согласен с точкой зрения Питера. В большой организации пытаться заставить кого-то другого решить такие проблемы, когда вы просто пытаетесь выполнить свою работу, нереально.
Шридхар Сарнобат

Многие крупные организации прямо противоположны тому, что предлагает @SridharSarnobat. Вы должны убедиться, что правильные люди решают такие проблемы, а попытка их обойти только усугубляет ситуацию.
Джеймс Мур

Ответы:


135

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

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

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

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

Ссылка .


40
Я думаю, что безответственно рекомендовать это без предупреждения о последствиях для безопасности. superuser.com/a/421084/121091 - лучший ответ IMO.
Ян Данн

5
@IanDunn Я бы согласился с вами в общей ситуации с SSH-клиентом, но, учитывая, что OP четко заявляет, что он сталкивается с этой проблемой при запуске сценариев, альтернативой является нарушение сценария при каждом изменении ключа хоста (и существует ряд причин, почему это может иметь место), который ответ, на который вы ссылались, не разрешается. Тем не менее, это правильная критика, поэтому я обновил свой ответ, чтобы указать на риск.
Кори

6
Я не могу поверить, что так много людей проголосовали за этот ответ, а также за то, что он принимается спрашивающим. Этот подход обходит проверки безопасности и подключает его к удаленному хосту. Проверьте, есть ли у файла known_hosts в папке ~ / .ssh / разрешение на запись. Если нет, то используйте этот ответ stackoverflow.com/a/35045005/2809294
ARK

Пока вы знаете, что делаете, это лучшее решение. У меня есть внутренний веб-сайт, к которому мы автоматически подключаемся, который имеет МНОГО, обновляя (фактически случайные) IP-адреса. Я добавил это в ~ / .ssh / config, и это просто работает. Имейте в виду, я ЗНАЮ, что этот сайт - то, чем я считаю, и если нет, то плохие парни не имеют никакого преимущества, так как я знаю, какие данные передаются.
user1683793

75

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

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

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

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

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

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

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

4
Или просто управляйте файлом known_hosts для всех машин в рамках настройки конфигурации вашей инфраструктуры.
Тило

1
обратите внимание, что ssh-keyscan не работает с ProxyCommand: marc.info/?l=openssh-unix-dev&m=108446567718763&w=2
Richlv

1
это не будет работать, как ожидалось. `ssh-keygen -F $IP`должно быть "`ssh-keygen -F $IP`"(в кавычках), в
противном

Или как пользователь, использующий возвращаемое значение ssh-kegen:ssh-keygen -F $IP >/dev/null || ssh-keyscan -H $IP >> ~/.ssh/known_hosts
Gohu

38

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


19

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


4
Безопасно ли позволять всем писать в known_hosts?
akaRem

2
@akaRem определенно нет. Обычно вы хотите, чтобы он был доступен для записи только пользователю, которому принадлежит эта .sshпапка.
2rs2ts

разрешения 0400оптимальны (пожалуйста, исправьте меня, если угодно), однако в моем случае проблема заключалась просто в том, что .sshпапка для моего пользователя сменила владельца - из-за этого мои собственные разрешения 0400 были аннулированы. sudoсмена владельца обратно ко мне решила мою проблему.
Чарни Кей

Этот исправил проблему для меня.
Шиваджи

14

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

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

10

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

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


Спасибо, это действительно спасло день. Но для чего последняя строка IdentityFile? Кажется, работает и без него ..
supersan

7

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

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

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

Failed to add the host to the list of known hosts 

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

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

5

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

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

5

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


4

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

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

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


2

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



0

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

chmod -R 700 ~/.ssh

Вы просите людей изменить разрешения для authorized_keys и открытых ключей с 644 до 700? А закрытый ключ от 600 до 700?
nurettin

0

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


-3

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

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


Это не отвечает на вопрос. Первоначальный (очень старый) вопрос касался возможности автоматического подтверждения таких запросов с помощью сценария.
MasterAM

Если это работает для него, может быть, это работает для других. Не нужно преуменьшать то, что действительно полезно
Mbotet

работает "ssh" не работает. Отображается для использования опций: ssh [..] [..] [..] [user @] имя хоста [команда]
P Satish Patro
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.