Регистрация Войти
Рейтинг:1
avatar Server

ошибка kex_exchange_identification с сервером Windows10 OpenSSH

флаг bm
AnthonyD973

Я установил OpenSSH-сервер на свой ПК с Windows 10 (вероятно, «домашнюю» версию, а не сервер Windows), используя руководство Майкрософт. я не менял C:/Windows/System32/OpenSSH/sshd_config_default файл (хотя я не думаю, что это здесь уместно в любом случае). я может войти на машину с терминала на той же машине:

локальный SSH

У меня есть еще одна машина, работающая в той же локальной сети (оба подключены к одному и тому же маршрутизатору SoHo). Из него попытка подключения к Windows 10 завершается неудачей:

kex_exchange_identification: Соединение закрыто удаленным хостом
Соединение закрыто портом 22 10.0.3.130

Согласно с этот ответ на другую похожую тему, эта ошибка возникает, когда сервер закрывает TCP-соединение во время криптографического обмена или что-то в этом роде. Итак, я посмотрел на брандмауэр Windows, но там является включенное входящее правило для TCP-порта 22 (и, кроме того, если бы это была проблема с отсутствующим правилом, клиент SSH просто бы тайм-аут, а не ошибка в kex_exchange_identification):

брандмауэр

Поэтому я попытался запустить Wireshark на сервере (10.0.3.130). Похоже, что сервер принимает рукопожатие TCP, затем другая машина (10.0.3.10) отправляет какой-то протокол SSH-пакет, а затем сервер просто закрывает соединение:

Wireshark OpenSSH запущен

Чтобы посмотреть, что произойдет, я зашел в Windows. Услуги приложение и остановил SSH-сервер OpenSSH service, затем попробовал то же самое, но результат с Wireshark тот же:

Wireshark OpenSSH остановлен

Единственное, что я заметил и чего не совсем понимаю, это то, что бег netstat -ab в администраторе PowerShell показывает, что на порту 22 есть активный прослушиватель, даже когда OpenSSH остановлен (я думаю, только для Windows...):

команда netstat

Так что, да... Я растоптан в этот момент. Любые идеи?

1391
0 + 0
Рейтинг:0
avatar Server
флаг bm
AnthonyD973

TL; DR: После небольшого поиска и попытки перезагрузки, как предлагали другие, я нашел простой обходной путь:

  1. Заставьте Windows запускать сервер OpenSSH на порту, который netstat -ab не отображается как снято путем добавления строки Порт номер порта в %programdata%\ssh\sshd_config [*] (замена номер порта по выбранному порту, конечно). Лично я выбрал порт 222, так как его легко запомнить.
  2. Добавьте входящее правило для порта TCP номер порта в Брандмауэр Защитника Windows с повышенной безопасностью.

Что я считаю неправильным, так это то, что я показал последним: это последнее изображение, кажется, показывает, что в моем случае порт 22 (на котором обычно находится сервер OpenSSH) уже занят другим, не связанным сервером (по... какой-то причине ).Таким образом, клиент SSH выполнял TCP-квитирование, которое принимал этот несвязанный сервер, а затем клиент отправлял пакет протокола OpenSSH (который несвязанный сервер не понимает), из-за чего этот несвязанный сервер просто закрывал TCP-соединение.

Теперь это является правда, я смог подключиться к серверу ssh через порт 22 с самого сервера. Я думаю, это потому, что подключение к локальный хост отправляет пакеты на петлевой интерфейс, который этот несвязанный сервер, вероятно, не прослушивал.

Поэтому логический обходной путь — просто переместить сервер OpenSSH на другой порт, который не используется, а затем добавить правило для входящего трафика на этот новый порт в брандмауэре Windows. Тем не менее, верным решением было бы найти, что этот несвязанный сервер прослушивает порт 22, а затем либо убить его, либо переместить. Это в другой порт.

[*]: В отличие от того, что я думал, файл конфигурации OpenSSH нет C:/Windows/System32/OpenSSH/sshd_config_default ; это на самом деле %programdata%\ssh\sshd_config согласно с это руководство от майкрософт. Так C:/Windows/System32/OpenSSH/sshd_config_default кажется, как следует из его названия, только для того, чтобы показать, какова конфигурация сервера OpenSSH, когда мы не меняем никакую конфигурацию в %programdata%\ssh\sshd_config, или когда этот файл не существует.

0 + 0
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.