Как убрать строгую проверку ключа RSA в SSH и в чем здесь проблема?

42

У меня есть сервер Linux, который при каждом подключении показывает сообщение об изменении ключа хоста SSH:

$ ssh root @ host1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@ @ ВНИМАНИЕ: УДАЛЕННАЯ ИДЕНТИФИКАЦИЯ ХОСТА ИЗМЕНИЛАСЬ! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@ ВОЗМОЖНО, ЧТО-то кто-то делает противное! Кто-то может подслушивать вас прямо сейчас (атака «человек посередине»)! Также возможно, что ключ хоста RSA был только что изменен. Отпечаток ключа RSA, отправленный удаленным хостом, составляет 93: a2: 1b: 1c: 5f: 3e: 68: 47: bf: 79: 56: 52: f0: ec: 03: 6b. Пожалуйста, обратитесь к системному администратору. Добавьте правильный ключ хоста в /home/emerson/.ssh/known_hosts, чтобы избавиться от этого сообщения. Оскорбительный ключ в /home/emerson/.ssh/known_hosts:377

Ключ хоста RSA для host1 изменился, и вы запросили строгую проверку. Ошибка проверки ключа хоста.

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

host1: ~ / .ssh # Чтение с удаленного хоста host1: Соединение установлено равноправным узлом Соединение с host1 закрыто.

Кто-нибудь знает, что происходит и что я мог сделать, чтобы решить эту проблему?

setatakahashi
источник
1
Это дублирует предыдущий вопрос: serverfault.com/questions/2988/…
Дрю Стивенс

Ответы:

68

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

Я предлагаю вам определить, почему он думает, что что-то изменилось, скорее всего, обновление SSH изменило ключи шифрования из-за возможной дыры в безопасности. Затем вы можете удалить эту конкретную строку из вашего файла known_hosts:

sed -i 377d ~/.ssh/known_hosts

Это д eletes линии 377 , как показано после двоеточия в предупреждение:

/home/emerson/.ssh/known_hosts:377

В качестве альтернативы вы можете удалить соответствующий ключ, выполнив следующее

ssh-keygen -R 127.0.0.1 (obviously replace with the server's IP)

Пожалуйста, НЕ удаляйте весь файл и убедитесь, что это действительно тот компьютер, к которому вы хотите подключиться, перед тем как очищать конкретный ключ.

Адам Гиббинс
источник
Не собирается удалять более 350 серверов из-за несоответствия одного ключа. Есть идеи, почему он продолжает закрывать соединение?
Сетатакахаси
Разве это не решается, когда вы удаляете соответствующую запись known_hosts? Если нет, можете ли вы запустить ssh-клиент в подробном режиме и вставить его куда-нибудь.
Адам Гиббинс
1
Он закрывает машину, потому что ключ хоста недействителен, как сказано. Если вы серьезно относитесь к безопасности, вам нужно проконсультироваться с администратором сервера, чтобы убедиться, что ключ хоста изменен по уважительной причине. Если это так, вы можете заменить его, как объяснил Адам.
Мэтью Флэшен
Я последовал вашему предложению, но $ sed -i "46 d" ~ / .ssh / known_hosts sed: 1: "/Users/myusr/.ssh ...": дополнительные символы в конце команды l, поэтому я удалил их вручную с помощью VIM и это сработало. Thanx!
Луис Рамирес-Монтероза
3
Синтаксис Адама почти правильный, но вам нужно пробел между «377» и «d». Кроме того, в OS X известные хосты расположены в ~ / .ssh / known_hosts; обратите внимание на отсутствие "." в имени файла.
ktappe 22.10.15
27

Я думаю, что хотя некоторые из ответов здесь касаются рекомендуемого курса действий в вопросе ФП, он не полностью отвечает на вопрос.

Вопрос гласит: «Как убрать строгую проверку ключа RSA в SSH и в чем здесь проблема?»

Проблема здесь заключается в том, что, как советуют некоторые другие, изменение хоста, вероятно, связано с переустановкой сервера (наиболее распространенный сценарий). И действительно, рекомендуемое решение - удалить поврежденный ключ из файла .ssh / authorized_keys с помощью встроенного sed.

Однако я не видел никаких ответов на конкретную часть вопроса « Как удалить строгую проверку ключа RSA в SSH ».

Вы можете удалить проверку StrictHostKey в файле конфигурации ssh, который обычно хранится в ~/.ssh/config.

Пример хост-блока представлен ниже:

Host 101
  HostName yourip|hostname
  User youruserid
  IdentityFile /path/to/keyfile
  Port 22
  StrictHostKeyChecking no

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

Джоэл Г Мэтью
источник
3
+1 Потому что этот пост фактически посвящен строгой проверке части сообщения об ошибке.
Шибуми
1
+1 от меня, а также за рассмотрение вопроса. В зависимости от факторов может быть что-то еще. Такой подход ухудшает проверку хоста со «строгого» до «некоторого» (моя терминология). В моей ситуации ssh оставил мне разрешение на вход в систему, потому что я хотел войти в систему, чтобы ввести пароль, и это было отключено «некоторой» проверкой хоста. Поэтому вы должны пойти дальше и указать ssh использовать / dev / null в качестве «UserKnownHostsFile». Это устанавливает проверку хоста в значение «none», и вышеупомянутые ПРЕДУПРЕЖДЕНИЯ DIRE применяются, поэтому не делайте это глобально или навсегда.
человек из
Это действительно элегантное решение. Спасибо, что поделился!
Леон - Хан Ли
10

Еще один способ удалить StrictHostKeyChecking, когда вам нужно сделать это только для одного сервера:

ssh <server> -o StrictHostKeyChecking=no
Грег Догерти
источник
Позволит вам войти, но не навсегда решить проблему.
Андрес Канелла
Когда я делаю это, это дает мне возможность добавить ключ, который затем навсегда решает проблему
Грег Догерти,
Возможно, у нас другая проблема? Я подключаюсь к серверу, который раньше имел другой IP.
Андрес Канелла
Если у вас есть сервер, данные которого были изменены, вам нужно удалить его из файла известных хостов (предварительно убедившись, что изменения верны), и добавить его новую информацию. Если у вас новый сервер, -o позволит вам подключиться к серверу и получить его информацию.
Грег Догерти
Я думаю, что на самом деле хорошей практикой является сохранение для параметра StrictHostKeyChecking значения YES в вашей конфигурации и использование этого переключателя только в том случае, если вы знаете, что подключаетесь к новому серверу или сами изменили ключи на старом сервере.
Мохак
5

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

Во-вторых, включите отладку ssh,

ssh -vvv user@host

и посмотрите, что это говорит вам, также попробуйте заглянуть в / var / log / secure и / var / log / messages на сервере, к которому вы пытаетесь подключиться для подсказок, sshd выдает хорошие сообщения об ошибках.

В-третьих, эта машина подключена к Интернету? Должны ли вы действительно разрешать вход с правами root?

Дейв Чейни
источник
1
+1 за комментарий пользователя root
Фахад Сада
Все, что требуется для того, чтобы произошла эта ошибка - это перезагружаемая целевая машина. Если вы подключаетесь к цели, которая находится на вашей стороне DMZ, атака MitM очень маловероятна.
ktappe
3

Вы получаете это, потому что что-то изменилось (например, новая сетевая карта, новый IP-адрес, изменение программного обеспечения сервера и т. Д.). В фокусе безопасности есть хорошая статья о защите ключей хоста SSH .

Просто удалите ключ (используя SFTP или аналогичный) с сервера, отредактировав $HOME/.ssh/known_hostsфайл, и примите новый при следующем подключении.

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


источник
2
Нееееет, пожалуйста, не делай этого. Это полностью аннулирует всю безопасность, которую обеспечивает эта функция. Удалите только тот ключ, который изменился, а не все известные_хосты.
Адам Гиббинс
5
Я не рекомендовал удалять файл known_hosts, я рекомендовал отредактировать его и удалить из него ключ.
Ой, прости, неправильно прочитал.
Адам Гиббинс
2
Это сообщение не может быть вызвано новым IP-адресом, а тем более новым NIC. Смотрите правильный ответ Адама Гиббинса.
bortzmeyer
1
Прежде чем вы проголосуете (я считаю, что люди очень довольны этим), сделайте свое исследование. Прочтите эту статью о безопасности , securityfocus.com/infocus/1806 . Я процитирую кое-что из этого: «Почему может измениться ключ хоста? Компьютер, к которому вы хотите подключиться, был перенесен на другое DNS-имя или IP-адрес или полностью заменен новым». Если ответ ужасно неправильный, пожалуйста, дайте шанс на исправление. В конце концов, это вики.
3

Поскольку «хост» [в широком смысле, это может быть все, от переустановки / мультизагрузки до совершенно другого компьютера с IP-адресом, к которому вы, например, подключались ранее], клиент ssh изменился, что дает вам ошибка.

Нет необходимости отключать строгую проверку, также не имеет смысла полное удаление сохраненных ключей.

Вполне возможно иметь два разных ключа, перечисленных в known_hosts для конкретного имени хоста или IP-адреса; предоставляя вам 2 варианта в зависимости от того, считаете ли вы, что вам может понадобиться «старый» ключ, который в данный момент хранится в known_hosts

Либо удалите конкретный ключ, на который он ссылается, в l377 of known_hosts для OP, либо оставьте оба

Самый простой способ сохранить оба, избегая удаления ключей в known_hosts, это

  1. Отредактируйте известные_хосты, добавив # в начале «старой» записи, на которую временно ссылаются известные_хосты [@ l377]
  2. Подключите [ssh к хосту], согласитесь на приглашение для добавления нового ключа «автоматически»
  3. Затем повторно отредактируйте known_hosts, чтобы удалить #

больше ответов в "Добавить правильный ключ хоста в known_hosts" / несколько ключей SSH хоста для имени хоста?

отметка
источник
Я не знал о трюке с двумя ключами. Это не задокументированное поведение, не так ли?
hackerb9