Пока я могу подключиться с клиента к серверу (openssh <servername> запрашивает данные для входа), я получаю "ssh: connect to host <servername> port 22: Connection refused"на другом.
Не являясь мастером UNIX (извините за все неправильные или отсутствующие термины в этом вопросе), я использую unison для синхронизации веток файловой системы. unison использует ssl-туннель через ssh. Вот почему у меня есть copssh, работающий на сервере (XP), а также на клиенте (чтобы иметь хороший клиент ssh).
На машине, на которой произошел сбой, была установлена новая версия copssh. Все машины работают под управлением XP. Я попытался отключить все локальные брандмауэры и искал файлы конфигурации openssl и ssh, но я полностью потерялся в поиске причины. Я даже не нашел полезного журнала или что-то в этом роде. Протокол событий Windows на сервере не содержит записей во время неудачного процесса подключения.
Как я могу это диагностировать? Я очень хочу это исправить.
В локальной сети используется беспроводной маршрутизатор N300 модели WNR2000v2. «Неисправный» клиент находится в проводной ЛВС, рабочий - в беспроводной. Однако он все еще работает, если я возьму рабочий клиент в проводную локальную сеть (я это проверил). Нигде нет правила блокировки порта 22.
Я просмотрел все связанные вопросы, но не нашел ничего сопоставимого, кроме ответов, охватывающих возможные причины, которые я уже проверил.
Отказ в соединении обычно означает две вещи. Либо существует брандмауэр, блокирующий соединение (это может быть сетевой брандмауэр на пути или брандмауэр хоста), либо порт не открыт на хосте, к которому вы пытаетесь подключиться.
Согласно тому, что вы говорите, брандмауэра нет, поэтому вам следует, во-первых, проверить, действительно ли порт на хосте открыт. Сделать netstat -n -p tcp и проверьте, прослушивает ли порт ssh. Вы должны увидеть такую строку:
TCP 0.0.0.0:22 0.0.0.0:0 LISTENING 2518
Если вы этого не сделаете, это означает, что по какой-то причине служба SSH не запущена, и вам следует проверить журналы copssh. Журналы могут отсутствовать в средстве просмотра событий, вам также следует проверить каталоги программы.
Если вы видите, что порт SSH прослушивает, значит, вас что-то блокирует. Вы должны запустить Wireshark и проверить, доходит ли предполагаемый трафик до вашего хоста, и попытаться найти, где на пути блокируется.
Я нашел это.
Не то чтобы у меня были хорошие шансы, поскольку это явно нигде не регистрировалось, но, проверив всю настройку моего IP, я решил, что у меня есть старая запись в файле хостов моего неисправного клиента (в Windows \ System32 \ drivers \ etc). Это привело к тому, что фактический IP-адрес сервера отличался от того, который сообщил DNS, а CheckHostIP был установлен на YES (конечно).
Поскольку машины были перемещены в локальную сеть DHCP несколько месяцев назад (!, Все остальное было бы слишком просто) назад, нет необходимости (и нет разрешения) в файле фиксированных IP-адресов. Скинул - работает.
Черт!
Простите за вопрос. И спасибо за ответ, даже если это не решение. (Если бы я последовал предложению анализа перехвата пакетов, я бы тоже его нашел. По этой причине я приму ответ AntiFubar, а не свой собственный.)