- Вопрос или проблема
- Ответ или решение
- Ошибка соединения с SSH-сервером WSL2: «kex_exchange_identification: read: Connection reset by peer»
- 1. Проверка конфигурации SSH-сервера
- 2. Проверка состояния службы SSH
- 3. Проверка сетевых настроек WSL2
- 4. Изучение лога аутентификации
- 5. Проверка брандмауэра
- 6. Проверьте сетевое окружение
- 7. Проверьте использование SSH ключей
- Заключение
Вопрос или проблема
Я следовал этому руководству, чтобы установить сервер SSH на Windows11 с WSL2 Ubuntu 24.04 LTS (дистрибутив свежий, кроме ssh ничего не установлено).
При первой попытке (3 дня назад) все было в порядке, и я смог подключиться к серверу с удаленного устройства. Сегодня я решил настроить root (выдать ему пароль) и добавить нового пользователя. После того как я сделал все это, я попытался удаленно подключиться к серверу, но получил ошибку ниже. (Примечание: я не знаю, влияет ли настройка root и добавление новых пользователей на сервер ssh)
Ошибка (xxx.xxx.xxx.xxx — это ipv4-адрес Windows):
➜ ssh [email protected] -p 2222 -v
OpenSSH_8.2p1 Ubuntu-4ubuntu0.11, OpenSSL 1.1.1f 31 Mar 2020
debug1: Чтение конфигурационных данных /home/user1/.ssh/config
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config строка 19: include /etc/ssh/ssh_config.d/*.conf не совпали с файлами
debug1: /etc/ssh/ssh_config строка 21: Применяются параметры для *
debug1: Подключение к xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] порт 2222.
debug1: Подключение установлено.
debug1: файл идентификации /home/user1/.ssh/id_rsa тип 0
debug1: файл идентификации /home/user1/.ssh/id_rsa-cert тип -1
debug1: файл идентификации /home/user1/.ssh/id_dsa тип -1
debug1: файл идентификации /home/user1/.ssh/id_dsa-cert тип -1
debug1: файл идентификации /home/user1/.ssh/id_ecdsa тип -1
debug1: файл идентификации /home/user1/.ssh/id_ecdsa-cert тип -1
debug1: файл идентификации /home/user1/.ssh/id_ecdsa_sk тип -1
debug1: файл идентификации /home/user1/.ssh/id_ecdsa_sk-cert тип -1
debug1: файл идентификации /home/user1/.ssh/id_ed25519 тип -1
debug1: файл идентификации /home/user1/.ssh/id_ed25519-cert тип -1
debug1: файл идентификации /home/user1/.ssh/id_ed25519_sk тип -1
debug1: файл идентификации /home/user1/.ssh/id_ed25519_sk-cert тип -1
debug1: файл идентификации /home/user1/.ssh/id_xmss тип -1
debug1: файл идентификации /home/user1/.ssh/id_xmss-cert тип -1
debug1: Локальная строка версии SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.11
kex_exchange_identification: read: Соединение сброшено соперником
На данный момент я не могу подключиться к серверу ssh с удаленного устройства. Тем не менее, я могу подключиться к нему из PowerShell на том же устройстве, запустив ssh user1@localhost -p 2222, что означает, что сервер работает.
На стороне сервера:
user1@computer:~$ nc -zv xxx.xxx.xxx.xxx 2222
Подключение к xxx.xxx.xxx.xxx 2222 порт [tcp/*] успешно!
Я убедился, что брандмауэр Windows разрешает TCP-соединение на порту 2222, добавив новое правило для входящих соединений. Я также пытался отключить брандмауэр, но это не помогло. На моем сервере не работает другое программное обеспечение безопасности (по крайней мере, не на Windows).
В sshd_config я явно указал:
Port 2222
PasswordAuthentification yes
AllowUsers user1 user2
Я следовал рекомендациям из https://superuser.com/a/857206/2314293, запуская /path/to/sshd -ddd -p 1022 и затем пытаясь подключиться к нему удаленно, но это ничего не выявило.
Запуская cat -f /var/log/auth.log, я также не вижу никакой информации о попытке удаленного подключения. Мне кажется, что я даже не подключаюсь к своему удаленному серверу, я пытался использовать ip-адрес wsl ubuntu, но он просто зависает на debug 1: Connecting to xxx.xx.x.xxx [xxx.xx.x.xxx] порт 2222.
Редактирование1:
WSL2 настроен на NAT-режим сети.
Ответ или решение
Ошибка соединения с SSH-сервером WSL2: «kex_exchange_identification: read: Connection reset by peer»
В рамках вашего запроса о проблемах подключения к SSH-серверу, установленному на WSL2 с Ubuntu 24.04 LTS, мы проанализируем различные аспекты и шаги, которые могут помочь в диагностике и решении проблемы.
1. Проверка конфигурации SSH-сервера
Вы предоставили конфигурацию SSH-сервера, которая выглядит достаточно корректно. Однако, давайте убедимся, что вы выполнили все необходимые действия по настройке:
-
Убедитесь, что в файле
/etc/ssh/sshd_configвсе опции указаны правильно. Конфигурация должна включать следующее:Port 2222 PermitRootLogin yes PasswordAuthentication yes AllowUsers user1 user2Если вы добавили нового пользователя, убедитесь, что он действительно прописан в строке
AllowUsers.
2. Проверка состояния службы SSH
После настройки конфигурации, рекомендуется перезапустить SSH-сервер:
sudo service ssh restartУбедитесь, что служба запущена корректно:
sudo service ssh status3. Проверка сетевых настроек WSL2
Поскольку WSL2 использует NAT, это может вызывать проблемы с подключением извне. Для того чтобы убедиться, что ваш SSH-сервер доступен, выполните следующие шаги:
-
Проверьте IP-адрес, который использует WSL2, с помощью команды:
hostname -IИспользуйте именно этот IP-адрес при попытке подключения из внешней сети.
-
Также убедитесь, что вы используете правильный порт 2222 при подключении, например:
ssh user1@<ваш_IP_WSL2> -p 2222
4. Изучение лога аутентификации
Вы упомянули, что при подключении к серверу нет записей в /var/log/auth.log. Это может указывать на то, что соединение на самом деле не проходит до сервера.
Попробуйте запустить SSH-сервер в режиме отладки:
/usr/sbin/sshd -d -p 2222Это должно дать больше информации о том, что происходит, когда вы пытаетесь подключиться.
5. Проверка брандмауэра
Вы уже проверили настройки Windows Firewall, однако стоит убедиться, что разрешён снимок входящих подключений на порт 2222. Для этого выполните следующее:
- Откройте меню «Пуск» и наберите
Windows Defender Firewall. - Перейдите в «Дополнительные параметры» и проверьте, что создано правило для порта 2222.
- Если возможно, временно отключите брандмауэр, чтобы проверить, не он ли вызывает проблемы.
6. Проверьте сетевое окружение
Если вы использовали VPN или прокси-сервер, попробуйте временно отключить их. Иногда они могут блокировать определённые соединения.
7. Проверьте использование SSH ключей
Убедитесь, что ключи SSH настроены корректно. Попробуйте подключиться без указания ключа, используя только пароль, если это допустимо.
Заключение
Если после выполнения всех вышеперечисленных шагов проблема всё ещё сохраняется, скорее всего, нужно будет рассмотреть другие варианты, такие как использование другого метода подключения (например, использование ngrok для туннелирования соединения) или миграция на другой дистрибутив Linux (если это возможно).
Если необходимо дальнейшее руководство, не стесняйтесь обращаться с дополнительными вопросами.