Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Компьютеры и программы

SSH-соединение сброшено на Windows

На чтение 9 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. ОБНОВЛЕНИЕ:
  3. отладка
  4. Ответ или решение
  5. Решение проблемы с сбросом соединения SSH на Windows
  6. Шаг 1: Проверка конфигурации OpenSSH
  7. Шаг 2: Проверка состояния сервисов
  8. Шаг 3: Применение IP-адреса вместо hostname
  9. Шаг 4: Проверка брандмауэра
  10. Шаг 5: Логи и диагностика
  11. Шаг 6: Проверка возможности подключения
  12. Заключение

Вопрос или проблема

Я пытаюсь установить OpenSSH на своей системе Windows.

Я пытался следовать как системной установке (например, этой), так и ручной установке из бинарных файлов. Я скопировал файлы OpenSSH в C:\Program Files и установил оттуда.

Сервер OpenSSH и агент, похоже, настроены правильно, но когда я пытаюсь подключиться по ssh к localhost, я всегда получаю следующую ошибку:

Соединение сброшено ::1 порт 22

Вот некоторые команды отладки:

Get-Service ssh-agent

  Статус   Имя               Отображаемое имя
  ------   ----               -----------
  Запущен  ssh-agent          Агент аутентификации OpenSSH

Get-Service sshd

  Статус   Имя               Отображаемое имя
  ------   ----               -----------
  Запущен  sshd               Сервер SSH OpenSSH

netstat -nao | find /i '":22"'
  TCP    0.0.0.0:22             0.0.0.0:0              ОЖИДАЕТ       5680
  TCP    [::]:22                [::]:0                 ОЖИДАЕТ       5680

Get-NetFirewallRule -Name *OpenSSH-Server* |select Name, DisplayName, Description, Enabled

  Имя                  Отображаемое имя           Описание Включено
  ----                  -----------           ----------- -------
  OpenSSH-Server-In-TCP Сервер OpenSSH (sshd)             True

whoami

  pcname\m.ceradini

ssh pcname\m.ceradini@localhost

  Соединение сброшено ::1 порт 22

Файл sshd_config является стандартным. Как предложено в другом руководстве, я также попытался закомментировать строку Match Group Administrators в sshd_config, но проблема остается.

Есть ли у вас идеи, что происходит? И как я мог бы попытаться исправить эту ошибку соединения?

Большое спасибо.

ОБНОВЛЕНИЕ:

Я здесь публикую ответы на некоторые вопросы и реплики. Подключение по ssh к моему собственному пользователю все еще не работает.

Для резюме я сделал следующее:

  • Удалил OpenSSH
  • Удалил все папки, связанные с .ssh и Open-SSH
  • Снова установил клиент и сервер OpenSSH (используя графический интерфейс Windows – из настроек) – и перезагрузил
  • Проверил, что все команды и службы, связанные с SSH, работают (Get-Command ssh, Get-Command sshd, Get-Command ssh-agent, Get-Service sshd, Get-Service ssh-agent)
  • Создал новый ключ для пользователя
  • Добавил открытый ключ в файл authorized_keys в папке .ssh
  • Закомментировал ‘Match Group administrators’ (как указано здесь) в sshd_config
  • Включил ‘PubkeyAuthentication’ в sshd_config
  • Проверил, что служба sshd запущена.

отладка

Get-Service sshd

Статус   Имя               Отображаемое имя
------   ----               -----------
Запущен  sshd               Сервер SSH OpenSSH

Поскольку sshd в стандартной конфигурации не обслуживает устройство обратного цикла,
localhost как удаленный адрес обычно не будет работать, если вы не начали туннель на этом порту ранее:

Пожалуйста, выполните следующую команду:

ssh pcname

whoami
pcname\m.ceradini

ssh -v pcname\m.ceradini
OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3
debug1: Провайдер аутентификаторов $SSH_SK_PROVIDER не был разрешен; отключение
ssh: Не удалось разрешить имя хоста pcname\\m.ceradini: Нет такого хоста.

Если хост не найден, используйте локальный IP-адрес, а не
127.0.0.1 или ::1

ssh -v 192.168.83.185
debug1: kex: алгоритм: curve25519-sha256
debug1: kex: алгоритм ключа хоста: ssh-ed25519
debug1: kex: сервер->клиент шифр: [email protected] MAC: <implicit> сжатие: none
debug1: kex: клиент->сервер шифр: [email protected] MAC: <implicit> сжатие: none
debug1: ожидая SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY получен
debug1: Ключ хоста сервера: ssh-ed25519 SHA256:v7C8pJ1ci+e/ZJKhgyIvZfENRyQHd0sUJSXv8PXIEDM
debug1: load_hostkeys: fopen C:\\Users\\m.ceradini/.ssh/known_hosts2: Нет такого файла или директории
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: Нет такого файла или директории
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: Нет такого файла или директории
debug1: Хост '192.168.83.185' известен и соответствует ключу хоста ED25519.
debug1: Найден ключ в C:\\Users\\m.ceradini/.ssh/known_hosts:1
debug1: rekey out после 134217728 блоков
debug1: SSH2_MSG_NEWKEYS отправлено
debug1: ожидаем SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS получено
debug1: rekey in после 134217728 блоков
debug1: Будет попытка ключа: sssapisa\\m.ceradini@TNE-Matteo ED25519 SHA256:ugTj7Iu5c0ZbiXgF6yMPO8Hru3rLp5ynP+Aku15WKX0 агент
debug1: Будет попытка ключа: C:\\Users\\m.ceradini/.ssh/id_rsa RSA SHA256:WgcHzwF1tPBwnvdmy9KriQjn+qLuDbOhR80Bmpw10O0
debug1: Будет попытка ключа: C:\\Users\\m.ceradini/.ssh/id_dsa
debug1: Будет попытка ключа: C:\\Users\\m.ceradini/.ssh/id_ecdsa
debug1: Будет попытка ключа: C:\\Users\\m.ceradini/.ssh/id_ecdsa_sk
debug1: Будет попытка ключа: C:\\Users\\m.ceradini/.ssh/id_ed25519
debug1: Будет попытка ключа: C:\\Users\\m.ceradini/.ssh/id_ed25519_sk
debug1: Будет попытка ключа: C:\\Users\\m.ceradini/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO получен
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected]>
debug1: SSH2_MSG_SERVICE_ACCEPT получен
debug1: Аутентификации, которые могут продолжаться: publickey,password,keyboard-interactive
debug1: Следующий метод аутентификации: publickey
debug1: Предложение открытого ключа: sssapisa\\m.ceradini@TNE-Matteo ED25519 SHA256:ugTj7Iu5c0ZbiXgF6yMPO8Hru3rLp5ynP+Aku15WKX0 агент
debug1: Аутентификации, которые могут продолжаться: publickey,password,keyboard-interactive
debug1: Предложение открытого ключа: C:\\Users\\m.ceradini/.ssh/id_rsa RSA SHA256:WgcHzwF1tPBwnvdmy9KriQjn+qLuDbOhR80Bmpw10O0
debug1: Сервер принимает ключ: C:\\Users\\m.ceradini/.ssh/id_rsa RSA SHA256:WgcHzwF1tPBwnvdmy9KriQjn+qLuDbOhR80Bmpw10O0
debug1: Аутентификация успешна (publickey).
Аутентифицировано к 192.168.83.185 ([192.168.83.185]:22).
debug1: канал 0: новый [клиент-сессия]
debug1: Запрос [email protected]
debug1: Вход в интерактивную сессию.
debug1: pledge: файловая система полная
debug1: ENABLE_VIRTUAL_TERMINAL_INPUT поддерживается. Чтение VTSequence из консоли
debug1: ENABLE_VIRTUAL_TERMINAL_PROCESSING поддерживается. Консоль поддерживает ansi-разбор
client_loop: отправить отключение: Соединение сброшено

Обычно вам не нужно использовать имя пользователя, так как ssh по умолчанию будет использовать вашего текущего пользователя. Так что исключение его устраняет источник ошибки. — Я подозреваю, что вы не должны использовать pcname\m.ceradini, а только m.ceradini в качестве имени пользователя. — Но я не являюсь основным пользователем Windows и в настоящее время не могу это проверить.

Что касается имени пользователя, я пробовал все возможные комбинации, но результат всегда один и тот же.

Вы проверяли настройки брандмауэра?

c:\Windows\system32\Firewall.cpl

Посмотрите на разрешенные приложения в используемых (требуемых) типах сетей для первого подсказки.

Затем продолжайте и проверьте в деталях:

Обратитесь к “Расширенные настройки > входящие правила” и проверьте, что есть правило, которое позволяет TCP-трафик для “локального порта” 22 на сервер OpenSSH.

Обновление:

Я также пробовал с полностью отключенным брандмауэром, чтобы быть уверенным, что это не проблема, связанная с брандмауэром

Спасибо за эту информацию. К сожалению, эти “ответы мистера Хорошего Парня” Windows

Get-NetFirewallRule -Name *OpenSSH-Server* |select Name, DisplayName, Description, Enabled

  Имя                  Отображаемое имя           Описание Включено
  ----                  -----------           ----------- -------
  OpenSSH-Server-In-TCP Сервер OpenSSH (sshd)             True

действительно не очень полезны, когда дело касается отладки, вместо того, чтобы заполнять презентации.

Следующий шаг:
Так как sshd в стандартной конфигурации не обслуживает устройство обратного цикла, localhost как удаленный адрес обычно не будет работать, если вы не начали туннель на этом порту ранее:

Пожалуйста, выполните следующую команду:

ssh pcname

где pcname должен быть настоящим именем вашего компьютера, но не заменяться на localhost.

Если хост не найден, используйте локальный IP-адрес, а не 127.0.0.1 или ::1

ssh 192.168.0.5

Обычно вам не нужно использовать имя пользователя, так как ssh по умолчанию будет использовать вашего текущего пользователя. Так что исключение его устраняет источник ошибки. — Я подозреваю, что вы не должны использовать pcname\m.ceradini, а только m.ceradini в качестве имени пользователя. — Но я не являюсь основным пользователем Windows и в настоящее время не могу это проверить.

Если это не сработает, пожалуйста, используйте подробный режим и предоставьте расширенный вывод:

ssh -v pcname

Ответ или решение

Решение проблемы с сбросом соединения SSH на Windows

С учетом описанной вами ситуации и предоставленных команд, давайте более подробно рассмотрим пути решения проблемы с подключением SSH на вашей системе Windows.

Шаг 1: Проверка конфигурации OpenSSH

В первую очередь важно убедиться, что конфигурация вашего SSH-сервера (sshd) установлена правильно. Откройте файл конфигурации sshd_config, находящийся в директории установки OpenSSH (обычно это C:\ProgramData\ssh\sshd_config) и проверьте следующие параметры:

  1. Параметр ListenAddress: Убедитесь, что он настроен на 0.0.0.0 или ::, чтобы сервер принимал соединения как по IPv4, так и по IPv6. По умолчанию, он может быть закомментирован, и это может вызвать проблемы с подключением.

    ListenAddress *

  2. Параметры аутентификации: Убедитесь, что у вас включена соответствующая аутентификация (например, PubkeyAuthentication, если вы используете ключи).

Шаг 2: Проверка состояния сервисов

Проверьте, что сервер SSH (sshd) и агент ключей (ssh-agent) действительно запущены. Вы это уже сделали, и результаты показывают, что оба сервиса работают. Это хороший знак.

Get-Service sshd
Get-Service ssh-agent

Шаг 3: Применение IP-адреса вместо hostname

Как было упомянуто, чтобы избежать проблем с разрешением имен, попробуйте подключиться через локальный IP-адрес, а не через localhost или ::1 (которые могут вызывать сбой, если SSH-сервер неправильно настроен для работы с обратным адресом).

Замените localhost на ваш локальный IP-адрес, например:

ssh -v 192.168.x.x

Шаг 4: Проверка брандмауэра

Даже если вы отключили брандмауэр, стоит проверить, установлены ли правила для OpenSSH. Это можно сделать с использованием следующей команды:

Get-NetFirewallRule -Name *OpenSSH*

Если правила присутствуют, убедитесь, что они включены. Если вы не уверены, попробуйте временно отключить брандмауэр для диагностики:

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

Шаг 5: Логи и диагностика

Если после всех вышеописанных действий проблема не решена, вам следует включить ведение логов для SSH. Вы можете сделать это, изменив файлы конфигурации. Например, добавьте или измените следующее:

LogLevel VERBOSE

Это увеличит уровень детализации логов и может помочь выявить причины сбоев. Логи обычно находятся в каталоге:

C:\ProgramData\ssh\logs

Шаг 6: Проверка возможности подключения

Постарайтесь выполнить команду SSH без указания имени пользователя:

ssh -v локальный_IP

При этом убедитесь, что вы используете корректный формат имени пользователя – только имя пользователя, без домена. Пример:

ssh -v m.ceradini@локальный_IP

Если проблема с подключением сохраняется, обратите внимание на вывод отладки, особенно на любые сообщения об ошибках.

Заключение

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

openssh windows
Оцените материал
Добавить комментарий

Капча загружается...

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности