Я работал вокруг этой проблемы путем создания пакетов на машине с эквивалентными аппаратными средствами к целевой машине и использования Studio Sun компилятор CC вместо gcc.
Соединение, которому отказывают обычно, означает две вещи. Или существует брандмауэр, блокирующий соединение (это может быть сетевой брандмауэр вдоль пути или брандмауэр хоста), или порт не открыт на хосте, с которым Вы пытаетесь соединиться.
Согласно тому, что Вы говорите, нет никакого брандмауэра, таким образом, Вы должны, во-первых, проверять, открыт ли порт действительно на хосте. Сделайте a netstat -n -p tcp
и проверьте, слушает ли ssh порт. Необходимо видеть строку как это:
TCP 0.0.0.0:22 0.0.0.0:0 LISTENING 2518
Если Вы не делаете затем, это означает, что по некоторым причинам сервис SSH не запустился, и необходимо проверить журналы copssh. Журналы не могли бы быть в конечном счете средством просмотра, необходимо также проверить каталоги программы.
Если Вы действительно видите, что порт SSH слушает, то что-то блокирует Вас. Необходимо выполнить Wireshark и проверку, если намеченный трафик достигает хоста, и попытайтесь найти, где вдоль пути заблокирован.
Я нашел его.
Не то, чтобы у меня был хороший шанс, так как это, очевидно, нигде не было зарегистрировано, но путем проверки моей целой установки IP, я полагал, что у меня была старая запись в файле hosts моего дефектного клиента (под Windows\System32\drivers\etc). Тот вывод к фактическому IP сервера, являющегося отличающимся от того, о котором сообщает DNS и CheckHostIP, был установлен на ДА (конечно).
Так как машины были перемещены в LAN DHCP месяцы (!, все остальное было бы слишком легко), назад, нет никакой потребности (и никакого допуска) для фиксированного файла хостов IP. Отброшенный это - работы.
Черт!
Извините за выяснение. И спасибо за ответ, даже если это не было решение. (Я следовал за пакетом, осуществляющим сниффинг аналитического предложения, я нашел его, также. Это - причина, я приму ответ AntiFubar, не мое собственное.)