
пару часов назад я изменил IP-адрес моего Windows-ПК и моего Raspberry Pi. До этого я мог подключаться к Pi через SSH без каких-либо проблем. Теперь, когда я пытаюсь подключиться, я получаю сообщение об ошибке, что кто-то пытается сделать "что-то отвратительное" и что мне следует обратиться к моему сетевому администратору.
Поэтому я сделал резервную копию своего файла "known-hosts" и создал пустой. Когда я сейчас подключаюсь по SSH через Windows-Terminal, я получаю следующий вывод:
Я понятия не имею, что это должно мне сказать, и что мне делать. Я уже перепрошил Pi, но безрезультатно. Независимо от того, сбрасываю ли я сетевую конфигурацию моего ПК или Pi или обоих в конфигурации маршрутизатора, сообщения об ошибках остаются прежними.
решение1
Сообщение
кто-то пытается сделать «что-то гадкое»
является результатом смены IP-адреса сервера.
Обычно это происходит, когда у пользователя known_hosts
на клиентском компьютере имеется информация о сервере, но часть сохраненной информации отличается от текущих параметров подключения (т. е. другой IP-адрес с тем же ключом хоста или наоборот), которые идентифицируют сервер.
Я думаю, что ваше затененное имя хоста — это не имя хоста, а IP-адрес. Изменение IP сервера вызвало сообщение. Использование имени хоста предотвратило бы это.
(важно знать, используете ли вы IP или имя хоста, поэтому предпочтительнее заменить информацию, а не удалять ее в целях конфиденциальности)
При удалении исходного known_hosts
файла эта ошибка должна была исчезнуть и замениться сообщением «первый контакт» с просьбой добавить новый ключ хоста в known_hosts
.
=> Это не является частью вашей текущей проблемы со входом в систему.
Проблема со входом
В журнале отладки указано:
- вы находитесь на клиенте Windows, который использует OpenSSH_for_Windows_8.1p1
- Разрешенные методы аутентификации:
publickey
иpassword
- Ваш клиент сохранил несколько идентификаторов, которые можно использовать для входа через «аутентификацию с открытым ключом» (что и пытаются сделать).
Но у учетной записи на сервере нет кулона хотя бы для одного из доступных идентификаторов,/root/.ssh/authorized_keys
и все пять запросов завершаются ошибкой.
=> Либо вы никогда не использовали этот метод аутентификации, либо, перепрошив свой сервер Pi, вы исключили уже существующий/root/.ssh/authorized_keys
, убив тем самым возможность использования этого метода запроса. - Если аутентификация с открытым ключом не удалась, SSH пытается"аутентификация по паролю", но возникает ошибка:
read_passphrase: can't open /dev/tty: No such file or directory
=> Очевидно«OpenSSH для Windows»не знает, куда выводить диалоговое окно входа в систему, и в итоге вход в систему не удается после трех разрешенных попыток.
Подведение итоговЯ совершенно уверен, что текущая информация в вашем вопросе:
До ваших фатальных изменений вы подключились черезаутентификация с открытым ключом.
Причина:Поскольку вы не изменили соответствующие настройки на клиенте иаутентификация по паролюне удается, эта проблема уже должна была присутствовать до ваших фатальных изменений. Но поскольку вы не знали о проблеме, должна была использоваться другая возможная аутентификация.
Из-за потери оригинала /root/.ssh/authorized_keys
на сервере, сервер не может авторизовать ваш доступ черезаутентификация с открытым ключоми все попытки входа в систему терпят неудачу.
Решения
- Восстановите обработку аутентификации пароля наOpenSSH для Windows.
Поскольку вы не дали никакой информации о том, как вы инициируете ssh-соединение, то не может быть правильного ответа.
Возможно, вы используете GUI-инструмент для подключения. Тогда может быть достаточно просто открыть окно терминала и запустить сеанс с помощью командной строки.
=> Вам следует создать новый вопрос с более подробной информацией для решения этой конкретной проблемы.
или
Восстановите или заново создайте
root/.ssh/authorized_keys
на сервере.
Чтобы добавить ключ вauthorized_keys
:C:\Users\???\.ssh\
Скопируйте на сервер только открытый ключ из пары ключей, имеющейся (или вновь созданной) на вашем клиенте Windows .- На сервере добавьте открытый ключ к пользователю
authorized_keys
:
cat <public_key_file> >> ~/.ssh/authorized_keys
- Проверьте вход
Для варианта 2: Если у вас возникли трудности с физическим доступом к локальной консоли сервера, вы можете загрузить Live Linux и установить его на USB-накопитель, чтобы подключиться к серверу с помощью аутентификации по паролю для повторного применения открытого ключа.
Обратите внимание: какRamhoundуже упоминалось использование пользователякореньдля удаленного подключения плохая идея. Лучше берите обычного пользователя и используйте sudo
для получения прав root.
решение2
Я нашел проблему. Неудивительно, что я это сделал.
Сообщение об ошибке со всеми этими символами "@", говорящее мне, что кто-то пытается "что-то отвратительное", было вполне понятным, а также удаляло содержимое файла "known_hosts". Но затем я совершил ошибку, пытаясь войти в систему с правами "root", которые, по-видимому, на самом деле отключены. Также я только что понял, что вы не можете войти в систему с именем пользователя в нижнем регистре после первой процедуры загрузки.
Вход под пользователем «test» с паролем «test» не сработал, а вот вход под пользователем «Test» и паролем «test» сработал.
Думаю, я узнал что-то новое.