Как убрать WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED
Oct 20, 2016 22:40 · 317 words · 2 minute read ssh
Давайте разберемся с известнейшей проблемой, часто возникающей при подключении по протоколу ssh!
По умолчанию, для большей безопасности, в настройках ssh значение параметра StrictHostKeyChecking установлено в ‘yes’. Именно поэтому при первом подключении к удаленному хосту можно увидеть следующее:
Введя в консоли ‘yes’, мы подтверждаем, что действительно хотим подключиться к этому хосту и отпечаток его ssh-ключа добавляется в файл
При повторной попытке подключения к хосту после изменения ключа на удаленном сервере (как правило, он меняется если была переустановлена операционная система или sshd), появляется сообщение с ошибкой:
Для устранения данной проблемы необходимо удалить строку с указанным ssh-ключом из файла /root/.ssh/known_hosts . Сделать это можно несколькими способами.
Первый (указан в самом сообщении с ошибкой):
Второй вариант удаления ключа:
Примечание. Номер строки с ssh-ключем, который нужно удалить, указывается с помощью ‘75d’.
Третий вариант удаления ключа (с использованием perl ):
После проделанных действий пробуем подключиться по ssh к удаленному хосту — проблема должна исчезнуть.
Исправляем ошибку: warning: remote host identification has changed!
Данная ошибка может появляться при попытке подключения к другому компьютеру через ssh и sftp протоколы.
Описание ошибки
Полностью она выглядит так:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:5VLqurxCsGZoX78FWhcaEQkHwAtq+Xzp1tBfOxKQQzE.
Please contact your system administrator.
Add correct host key in /home/ajiekceu4/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/ajiekceu4/.ssh/known_hosts:5
remove with:
ssh-keygen -f «/home/ajiekceu4/.ssh/known_hosts» -R sysadmin.ru
ECDSA host key for sysadmin.ru has changed and you have requested strict checking.
Host key verification failed.
Причина возникновения ошибки
Как видно из описания, данная ошибка может появляться в том случае, когда на устройстве, к которому вы пытаетесь подключиться, изменился ключ и он не совпадает с тем ключом, который вы уже получали ранее, когда осуществляли подключение к этому устройству в предыдущие разы. Причины могут быть разные:
- Был изменен сертификат на устройстве и соответственно поменялся ECDSA ключ (из соображений безопасности, например);
- Переустановлена ОС на устройстве и соответственно изменился сертификат;
- Кто то пытается вас обмануть;
Как ее исправить
Если вы точно знаете, что сертификат на удаленном устройстве, к которому вы пытаетесь подключиться изменился и это не попытка вас обмануть со стороны заинтересованных лиц, то исправить эту ошибку очень просто. Необходимо просто удалить текущий ключ для данного домена (в нашем примере sysadmin.ru), сделать это можно командой, которая описана в самом тексте ошибки:
В случае успеха, вывод команды должен быть примерно таким:
После этого, необходимо еще раз попытаться подключиться к удаленному хосту и подтвердить установку нового ключа, написав «yes»
Устранение неполадок SSH: ошибки протокола
В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить конкретные ошибки:
-
: здесь вы узнаете, как обнаружить и исправить ошибки подключения к серверу. : поможет устранить проблемы с парольной аутентификацией или сбросом SSH-ключей. : это руководство поможет исправить ошибки ветвления процессов, валидации оболочки и доступа к домашнему каталогу.
В данном руководстве вы узнаете, что делать, если сбрасываются клиентские соединения, клиент жалуется на шифрование или возникают проблемы с неизвестным или измененным удаленным хостом.
После успешного подключения протокол SSH согласовывает зашифрованное соединение с клиентом на основе установления доверия. Есть несколько уникальных проблем, которые могут возникнуть на этом этапе. В этом мануале рассматриваются способы их определения, устранения и предотвращения.
Требования
- Убедитесь, что можете подключиться к виртуальному серверу через консоль.
- Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.
Общие ошибки
Ошибка при проверке ключа хоста
Когда к серверу подключается SSH-клиент, сервер пытается идентифицировать себя с помощью ключа хоста. Если главный ключ изменился, вы можете увидеть такое предупреждение:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
.
В PuTTY предупреждение выглядит так:
WARNING — POTENTIAL SECURITY BREACH!
The server’s host key does not match the one PuTTY has
cached in the registry. This means that either the
Server administrator has changed the host key, or you
.
Обычно причиной этой ошибки является:
- Восстановление сервера с помощью снапшота или резервной копии.
- Перенос плавающего IP на другой сервер.
- Переустановка SSH-сервера с помощью менеджера пакетов
Чтобы решить эту проблему, вы можете очистить ключи хоста.
Соединение закрыто или сброшено
Иногда соединения устанавливаются на уровне сокета, но сбрасываются во время проверки ключей хоста. В PuTTY эта ошибка выглядит так:
Server Unexpectedly closed network connection
Клиент OpenSSH выдаёт такую ошибку:
Connection closed by 111.111.111.111 port 22
Эта ошибка, как правило, происходит по следующим причинам:
- Сбой или ошибки сервиса SSH.
- Сервис SSH не может инициализировать подключение из-за отсутствия ключей хоста сервера.
В таком случае необходим более тщательный анализ выходных данных протокола. В большинстве случаев данные нужно исследовать через веб-консоль и убедиться, что сервис в данный момент запущен и связан с требуемым портом.
Если сервис работает должным образом, убедитесь, что ключи хоста доступны. Если это не так, сгенерируйте и снова.
Ошибки переговоров с хостом
При инициировании протокола SSH генерируется общий секретный ключ. Это делается посредством шифрования, согласованного между клиентом и хостом. Если на данном этапе возникает несоответствие, переговоры срываются, и вы можете увидеть такие ошибки в PuTTY:
Couldn’t agree a client-to-server cipher (available: aes128-ctr, aes192-ctr, aes256-ctr)
Клиент OpenSSH сообщит:
Unable to negotiate with 111.111.111.111: no matching key exchange method found.
Their offer: diffie-hellman-group1-sha1
Источником этой ошибки может быть:
- Несовпадение реализаций клиента и хоста (если вы используете современный клиент OpenSSH и устаревший хост, последний может просто не поддерживать шифрования клиента).
- Изменение списка шифрования клиента SSH (возможно, сервер его не поддерживает).
Чтобы решить эту проблему, вам необходимо правильно настроить шифрование на SSH-клиенте.
Устранение неполадок
Сброс ключей известных хостов
Ключи хоста обычно хранятся в файле
/.ssh/known_hosts клиента OpenSSH. PuTTY обычно хранит их в реестре Windows (HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys).
В PuTTY можно использовать диалоговое окно, чтобы разрешить подключение и обновить реестр (просто выберите Yes). Кроме того, вы можете удалить запись вручную.
На клиенте OpenSSH вы можете найти записи хоста в файле
/.ssh/known_hosts и удалить их вручную. Также можно использовать команду ssh-keygen.
ssh-keygen -R your_server_ip
Команда попытается получить доступ и очистить соответствующую запись хоста в файле known_hosts:
# Host 111.111.111.111 found: line 2
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old
После этого попробуйте снова подключиться к серверу.
Проверка и генерирование SSH-ключей
Если у хоста SSH нет собственного закрытого ключа и он не может сгенерировать общий секретный ключ, соединение будет сброшено. Откройте каталог /etc/ssh и попробуйте найти в нём группу файлов с именами sshd_host_*_key. Среди них должен быть файлы с расширением .pub.
Если таких файлов нет, сгенерируйте их с помощью команды ssh-keygen.
Команда выведет сгенерированные ключи:
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
Теперь попробуйте снова подключиться к серверу.
Настройка поддерживаемых шифров SSH
Вы можете настроить поддерживаемые SSH-шифры на клиентской машине, если нужна поддержка устаревшего шифрования (например, SHA1). Это не очень распространенная проблема; обычно она случается, если вы используете новый клиент SSH для подключения к устаревшему SSH-серверу, и они поддерживают разные шифры.
В OpenSSH поддержку SHA1 можно настроить с помощью опции KexAlgorithms. Введите в командную строку:
openssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@your_server_ip
Клиент PuTTY должен поддерживать группу Диффи-Хеллмана (Connection → SSH → Kex).
Если у вас не получается самостоятельно исправить ошибки протокола SSH, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.
Rukovodstvo
статьи и идеи для разработчиков программного обеспечения и веб-разработчиков.
Как исправить: «ВНИМАНИЕ: ИДЕНТИФИКАЦИЯ УДАЛЕННОГО ХОСТА ИЗМЕНИЛАСЬ» на Mac и Linux
SSH или Secure Shell — очень распространенный способ безопасного доступа к удаленным машинам, обычно через командную строку. Он направлен на то, чтобы ваше соединение и, следовательно, все передаваемые данные были свободны от подслушивания. Из-за этого в популярные клиенты SSH, такие как OpenSSH [https://en.wikipedia.org/wiki/OpenSSH], встроено довольно много проверок, которые гарантируют, что ваше соединение не будет скомпрометировано. Ниже приведен пример одной из этих проверок, которая определяет, когда отпечаток пальца
Время чтения: 3 мин.
SSH или Secure Shell — очень распространенный способ безопасного доступа к удаленным машинам, обычно через командную строку. Он направлен на то, чтобы ваше соединение и, следовательно, все передаваемые данные были свободны от подслушивания. Из-за этого в популярные клиенты SSH, такие как OpenSSH , встроено немало проверок, которые гарантируют, что ваше соединение не будет скомпрометировано.
Примером одной из этих проверок является следующий, который определяет, когда был изменен отпечаток пальца сервера:
Когда вы подключаетесь к серверу через SSH, он получает отпечаток ключа ECDSA , который затем сохраняет в вашем домашнем каталоге в
/.ssh/known_hosts . Это делается после первого подключения к серверу, и вам будет предложено следующее сообщение:
Если вы введете «да», то отпечаток пальца будет сохранен в known_hosts , который SSH затем проверяет каждый раз, когда вы подключаетесь к этому серверу.
Но что произойдет, если ключ ECDSA сервера изменился с момента вашего последнего подключения к нему? Это настораживает, потому что на самом деле это может означать, что вы подключаетесь к другому серверу, не зная об этом. Если этот новый сервер является вредоносным, он сможет просматривать все данные, отправляемые в ваше соединение и из него, которые могут быть использованы любым, кто настраивал сервер. Это называется атакой «человек посередине» . Этот сценарий в точности соответствует сообщению «ПРЕДУПРЕЖДЕНИЕ: ИДЕНТИФИКАЦИЯ УДАЛЕННОГО ХОЗЯКА ИЗМЕНИЛАСЬ!» сообщение пытается вас предупредить.
Конечно, это не всегда так, и есть много причин для изменения отпечатка ключа ECDSA для сервера. В моем случае у меня был эластичный IP-адрес на AWS, и я назначил его другому серверу после повторного развертывания нашего приложения. IP-адрес и имя хоста, к которым я подключался, были одинаковыми, но базовый сервер был другим, что и заставило SSH-клиент выдать это предупреждение.
Устранение проблемы
Если вы на 100% уверены, что это ожидаемое поведение и что нет потенциальной проблемы с безопасностью, вам необходимо исправить проблему, прежде чем продолжить.
Я нашел два самых простых способа решить эту проблему.
Разрешить вручную через known_hosts
- В предупреждающем сообщении найдите строку, которая сообщает вам, где находится проблемный ключ ECDSA в файле known_hosts В моем примере в этой строке говорилось «Нарушение ключа ECDSA в /Users/scott/.ssh/known_hosts:47», что относится к строке 47.
- Откройте known_hosts указанный в предупреждающем сообщении.
- Удалить строку, указанную в предупреждающем сообщении
Удалив эту строку, у вашего SSH-клиента не будет отпечатка ключа ECDSA для сравнения, и он снова попросит вас проверить подлинность сервера при следующем подключении. После этого у вас будет новый отпечаток в нашем known_hosts для этого сервера, и предупреждение исчезнет.
Разрешить с помощью ssh-keygen
Другое решение — использовать утилиту ssh-keygen known_hosts ключа из вашего файла known_hosts, что можно сделать с помощью следующей команды: