Вопрос или проблема
Ранее я мог подключиться по SSH к серверу Ubuntu 16.04.2 до перезагрузки. После перезагрузки я попытался подключиться по SSH, но получил сообщение ssh_exchange_identification: read: Connection reset by peer.
Странно, но после ожидания около 10 минут я смог подключиться к серверу. Существует ли временная блокировка? Если да, то как ее сбросить?
Ниже приведены мои конфигурации на сервере:
-
sshd: ALLв /etc/hosts.allow -
пусто в /etc/hosts.deny
-
брандмауэр неактивен
ufw status Status: inactive -
подключение по SSH к серверу как
rootс использованием публичного ключа -
включены следующие настройки в
/etc/ssh/sshd_configPermitRootLogin without-password
PubkeyAuthentication yes
StrictModes no
PasswordAuthentication yes
-
в /root/.ssh/config у меня следующее:
Host *
StrictHostKeyChecking no
-
публичный ключ клиента находится на сервере в
/root/.ssh/authorized_keys
Подробный лог здесь:
ssh -vvv [email protected]
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /root/.ssh/config
debug1: /root/.ssh/config line 6: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "192.168.0.100" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.0.100 [192.168.0.100] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
ssh_exchange_identification: read: Connection reset by peer
Спасибо!
Как я решил проблему: я зашел на хост-машину и выполнил несколько команд.
sudo mkdir /var/run/sshd
sudo chmod 755 -R /var/run/sshd
sudo service ssh restart
После этого я подключился к машине.
Ответ или решение
Причина проблемы, с которой вы столкнулись при попытке подключиться к серверу Ubuntu 16.04.2 через SSH после перезагрузки, заключается в ошибке «ssh_exchange_identification: read: Connection reset by peer». Это довольно распространенная проблема, на которую могут влиять различные факторы. Давайте подробно рассмотрим, как можно её диагностировать и решить, анализируя предоставленные данные и общий контекст.
Теория
Ошибка «Connection reset by peer» обычно означает, что TCP-соединение, установленное между клиентом и сервером, было неожиданно разорвано. Это может быть вызвано несколькими причинами, которые могут включать в себя:
- Проблемы с сетевой конфигурацией: Может быть настроен файрволл или другой сетевой компонент, который завершает соединение.
- Конфигурационные ошибки SSH: Ошибки в настройках SSH, как на клиенте, так и на сервере, могут также вызывать подобные разрывы.
- Проблемы с файловым доступом: Отсутствие необходимых директорий или неправильно установленные права доступа могут привести к сбоям в работе SSH.
- Нагрузочные и системные проблемы: Некоторые демоны сервера могут не запускаться сразу после перезагрузки из-за переполнения системы или зависимостей от других сервисов.
Пример
Из предоставленной информации видно, что после перезагрузки системы возникла проблема с отсутствием директории /var/run/sshd, что и вызвало сбой при попытке установить SSH-соединение. После создания этой директории вручную и перезагрузки сервиса SSH проблема была решена.
Анализ конфигурации SSH, приведенной в описании, показывает, что основные параметры заданы корректно для разрешений на вход для пользователя root по публичному ключу:
PermitRootLogin without-passwordPubkeyAuthentication yesPasswordAuthentication yes
Однако стоит заметить, что использование root-доступа через SSH, особенно с включенной аутентификацией по паролю, увеличивает риски безопасности. Настоятельно рекомендуется предусмотреть дополнительные меры безопасности, например, ограничение доступа по IP и использование fail2ban.
Применение
Вот шаги для диагностики и решения подобных проблем:
-
Проверка системных логов: Исследуйте файлы
/var/log/syslogи/var/log/auth.logдля поиска специфических ошибок, касающихся SSH и других сетевых сервисов. -
Проверка конфигураций: Убедитесь, что конфигурационные файлы
/etc/ssh/sshd_configи/etc/hosts.allowне содержат ошибок синтаксиса или конфликтующих правил. -
Проверка файловой системы: Убедитесь, что все необходимые SSH-директории существуют и имеют правильные права доступа. При необходимости создайте их и установите корректные права командой
sudo chmod. -
Перезапуск сетевых и SSH-сервисов: Используйте команды
sudo systemctl restart sshиsudo systemctl restart networkingдля перезапуска служб, чтобы убедиться, что все изменения были применены. -
Отклонение избыточных настроек: Внимательно изучите необязательные параметры, такие как
StrictModes no, который может ослабить безопасность вашего сервера, гарантируя, что это необходимо для вашей конфигурации. -
Автоматизация исправления проблем: Создайте скрипт и настройте его для автоматического выполнения после перезагрузки, чтобы предотвращать повторное возникновение данной ошибки, если это происходит регулярно.
Рекомендации
Для повышения устойчивости вашей системы и предотвращения подобных проблем в будущем, рекомендуется:
-
Обновление системы: Обновите вашу операционную систему до более новой версии, например Ubuntu 18.04 или Ubuntu 20.04 LTS, где многие известные баги уже исправлены.
-
Оптимизация SSH-настроек: Рассмотрите возможность ограничения протоколов SSH, отключения входа root или использования других мер безопасности, таких как двухфакторная аутентификация.
-
Регулярный мониторинг и аудит: Проводите регулярные аудиты системных логов и мониторинг работы серверов для своевременного выявления потенциальных аномалий.
Применяя эти рекомендации, вы сможете улучшить надежность SSH-соединений и общую безопасность сервера в Ubuntu.