Network error connection refused putty что делать

купил виртуальный хост, дали мне ip-адрес, логин и пароль, только подключится к нему немогу, сразу после нажатия появляется консоль и выскакивает ошибка — "PuTTY Fatal Error — Network error: Connection refused" как исправить? может кто-то сталкивался с таким и знайтет как решить техподержка говорит что я неверно пароль ввожу, этого быть не может, все тщательно проявлял. Брандмауэр Защитника Windows отключал. Толку ноль!

OS: Windows 10, Клиент: PuTTY

UPD: через браузер заходит. По SSH не работает. Подключится могу лишь через VPN или через 3G-интернет.

Предложение от 8host.com

В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить ошибки:

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

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

Требования

  • Убедитесь, что можете подключиться к виртуальному серверу через консоль.
  • Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.

Основные ошибки

Разрешение имени хоста

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

На клиенте OpenSSH эта команда:

может выдать ошибку:

ssh: Could not resolve hostname example.com: Name or service not known

В PuTTY может появиться такая ошибка:

Unable to open connection to example.com Host does not exist

Чтобы устранить эту ошибку, можно попробовать следующее:

  • Проверьте правильность написания имени хоста.
  • Убедитесь, что вы можете разрешить имя хоста на клиентской машине с помощью команды ping. Обратитесь к сторонним сайтам (WhatsMyDns.net, например), чтобы подтвердить результаты.

Если у вас возникают проблемы с разрешением DNS на любом уровне, в качестве промежуточного решения можно использовать IP-адрес сервера, например:

ssh user@111.111.111.111
# вместо
ssh user@example.com.

Истечение времени соединения

Эта ошибка значит, что клиент попытался установить соединение с SSH-сервером, но сервер не смог ответить в течение заданного периода ожидания.

На клиенте OpenSSH следующая команда:

выдаст такую ошибку:

ssh: connect to host 111.111.111.111 port 22: Connection timed out

В PuTTY ошибка выглядит так:

Network error: Connection timed out

Чтобы исправить ошибку:

  • Убедитесь, что IP-адрес хоста указан правильно.
  • Убедитесь, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт. Это поможет вам определить, не связана ли проблема с самим сервером.
  • Проверьте правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP.
Читайте также:  Как отключить субтитры mkv

Отказ в соединении

Эта ошибка означает, что запрос передается на хост SSH, но хост не может успешно принять запрос.

На клиенте OpenSSH следующая команда выдаст ошибку:

ssh user@111.111.111.111
ssh: connect to host 111.111.111.111 port 22: Connection refused

В PuTTY ошибка появится в диалоговом окне:

Network error: Connection refused

Эта ошибка имеет общие с ошибкой Connection Timeout причины. Чтобы исправить её, можно сделать следующее:

  • Убедиться, что IP-адрес хоста указан правильно.
  • Убедиться, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт.
  • Проверить правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP, и что брандмауэр не блокирует этот порт.
  • Убедиться, что сервис запущен и привязан к требуемому порту.

Рекомендации по исправлению ошибок подключения

Брандмауэр

Иногда проблемы с подключением возникают из-за брандмауэра. Он может блокировать отдельные порты или сервисы.

В разных дистрибутивах используются разные брандмауэры. Вы должны научиться изменять правила и политики своего брандмауэра. В Ubuntu обычно используется UFW, в CentOS – FirewallD. Брандмауэр iptables используется независимо от системы.

Читайте также:

Чтобы настроить брандмауэр, нужно знать порт сервиса SSH. По умолчанию это порт 22.

Чтобы запросить список правил iptables, введите:

Такой вывод сообщает, что правил, блокирующих SSH, нет:

Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Если в выводе вы видите правило или политику по умолчанию REJECT или DROP, убедитесь, что цепочка INPUT разрешает доступ к порту SSH.

Чтобы запросить список правил FirewallD, введите:

Список, появившийся на экране, содержит все сервисы, которые поддерживаются брандмауэром. В списке должно быть правило:

dhcpv6-client http ssh

Если вы настроили пользовательский порт SSH, используйте опцию —list-ports. Если вы создали пользовательское определение сервиса, добавьте опцию —list-services, чтобы найти SSH.

Чтобы проверить состояние UFW, введите:

Команда вернёт доступные порты:

Status: active
To Action From
— —— —-
22 LIMIT Anywhere
443 ALLOW Anywhere
80 ALLOW Anywhere
Anywhere ALLOW 192.168.0.0
22 (v6) LIMIT Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)

В списке должен быть порт SSH.

Проверка состояния сервиса SSH

Если вы не можете подключиться к серверу по SSH, убедитесь, что сервис SSH запущен. Способ сделать это зависит от операционной системы сервера. В более старых версиях дистрибутивов (Ubuntu 14.04, CentOS 6, Debian 8) используется команда service. Современные дистрибутивы на основе Systemd используют команду systemctl.

Метод проверки состояния сервиса может варьироваться от системы к системе. В более старых версиях (Ubuntu 14 и ниже, CentOS 6, Debian 6) используется команда service, поддерживаемая системой инициализации Upstart, а в более современных дистрибутивах для управления сервисом используется команда systemctl.

Примечание: В дистрибутивах Red Hat (CentOS и Fedora) сервис называется sshd, а в Debian и Ubuntu – ssh.

Читайте также:  Listening for connections on localhost 25

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

service ssh status

Если процесс работает должным образом, вы увидите вывод, который содержит PID:

ssh start/running, process 1262

Если сервис не работает, вы увидите:

В системах на основе SystemD используйте:

systemctl status sshd

В выводе должна быть строка active:

sshd.service — OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Mon 2017-03-20 11:00:22 EDT; 1 months 1 days ago
Process: 899 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 906 (sshd)
CGroup: /system.slice/sshd.service
├─ 906 /usr/sbin/sshd -D
├─26941 sshd: [accepted]
└─26942 sshd: [net]

Если сервис не работает, вы увидите в выводе inactive:

sshd.service — OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: inactive (dead) since Fri 2017-04-21 08:36:13 EDT; 2s ago
Process: 906 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
Process: 899 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main P >

Чтобы перезапустить сервис, введите соответственно:

service ssh start
systemctl start sshd

Проверка порта SSH

Существует два основных способа проверить порт SSH: проверить конфигурационный файл SSH или просмотреть запущенный процесс.

Как правило, конфигурационный файл SSH хранится в /etc/ssh/sshd_config. Стандартный порт 22 может переопределяться любой строкой в этом файле, определяющей директиву Port.

Запустите поиск по файлу с помощью команды:

grep Port /etc/ssh/sshd_config

Если вы уже убедились, что сервис работает, теперь вы можете узнать, работает ли он на требуемом порте. Для этого используйте команду ss. Команда netstat –plnt выдаст аналогичный результат, но команду ss рекомендуется использовать для запроса информации сокета из ядра.

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

State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:22 *:* users:(("sshd",p > LISTEN 0 128 . 22 . * users:(("sshd",p >

Символ * и 0.0.0.0 указывает, что все интерфейсы сервера прослушиваются. Строка 127.0.0.1 значит, что сервис не является общедоступным. В sshd_config директива ListenAddress должна быть закомментирована, чтобы прослушивать все интерфейсы, или должна содержать внешний IP-адрес сервера.

Если у вас не получается самостоятельно настроить соединение SSH, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.

Вступление
С оборудованием Cisco я работаю уже несколько лет, но с подобной проблемой столкнулся впервые. Хотя может и не впервые :). Точно сказать не могу, так как всякого рода траблов и непоняток было много, из-за того что я настраивал в работу и изучал их одновременно. Но раньше скорее всего все решалось обычным хардрезетом, теперь же я разобрался в чем дело.

Что было поводом?
В один прекрасный день мне понадобилось зайти удаленно на один из роутеров Cisco, чтобы посмотреть вывод sh ver. Обычно я захожу со своей машины с OS Windows посредством Putty. Как обычно окно терминала открылось, и…, не выдав никакой текстовой информации с велкомом и приглашением к логину, сразу же закрылось без объяснения причин.

Попробовал с линуксового сервера:

]$ telnet 10.15.xxx.yy
Trying 10.15.xxx.yy.
telnet: connect to address 10.15.xxx.yy: Connection refused
telnet: Unable to connect to remote host: Connection refused

Читайте также:  Boot device led горит красным asus

Попробовав еще несколько раз с тем же результатом с других хостов я решил немного
попинать головой стену подумать 🙂
И вот что обнаружилось и придумалось.

Так как фаервола и ACL от меня в сторону роутера не было, да и я заходил на роутер перед этим много раз на прошлой неделе, настраивая тоннель, то я сделал вывод, что закончились свободные vty line. Конечно, дошел к этому выводу я не так быстро и сразу, были разные предположения, но помогло то, что глюков в циске я еще не встречал, роутер по информации маршрутизации и cdp работал, в чудеса особо не верю, заходил на роутер буквально пару дней назад и еще помню примерно конфиг, плюс на днях читал блог одного цисковода, где он как раз тюннинговал эти самые vty line.

Что было сделано?
На прошлой неделе я настраивал на этом роутере (к слову сказать Cisco 1841) тоннель через партнерские сети к другому такому же роутеру. Что бы окно терминала не закрывалось из-за бездействия при выводе дебага, в настройках line vty я установил параметр exec-timeout 0 0 (время бездействия в 0 минут 0 секунд, то есть сессия будет висеть практически вечно).
В процессе настройки несколько раз выходил нештатно, то есть просто закрывал окно терминала. В итоге все мои telnet-сессии остались открытыми и занятыми и когда я попытался очередной раз зателнетится на роутер — меня не пустило.
Повезло только то, что был еще открыт доступ по http протоколу и это помогло диагностировать и решить проблему.

Что нужно сделать ?

Нужно посмотреть сводный статус TCP-соединений:

cisco#show tcp brief
TCB Local Address Foreign Address (state)
8173B78C 10.15.xxx.yy.23 10.15.aa.bb.2530 ESTAB
.
80CCEB24 10.15.xxx.yy.23 10.15.aa.bb.4427 ESTAB

Первая колонка — это TCB адрес (Transmission Control Block адрес установленого TCP-соединения). По аналогии с *nix, можно сказать что это PID процесса, который можно убить:

router#clear tcp tcb 8173B78C
[confirm]

для подтверждения нажав «y» мы убиваем данную сессию.

Таким образом, сняв TCP-сессии, я освободил vty линии и смог зайти телнетом на роутер.

Хочу заметить еще, что более подробно о TCP-соединении можно узнать, если ввести команду:

show tcp tcb [TCB address]

router#show tcp tcb 80CCF254
Connection state is ESTAB, I/O status: 1, unread input bytes: 1
Local host: 10.15.xxx.yy, Local port: 23
Foreign host: 10.15.aa.bb, Foreign port: 1840

Enqueued packets for retransmit: 1, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x374828A8):
Timer Starts Wakeups Next
Retrans 123 7 0x374829CB
TimeWait 0 0 0x0
AckHold 128 11 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0

iss: 2866020113 snduna: 2866027408 sndnxt: 2866027946 sndwnd: 65097
irs: 672352072 rcvnxt: 672352285 rcvwnd: 3916 delrcvwnd: 212

SRTT: 302 ms, RTTO: 319 ms, RTV: 17 ms, KRTT: 0 ms
minRTT: 156 ms, maxRTT: 564 ms, ACK hold: 200 ms
Flags: passive open, higher precedence, retransmission timeout

Datagrams (max data segment is 536 bytes):
Rcvd: 248 (out of order: 0), with data: 137, total data bytes: 212
Sent: 166 (retransmit: 7, fastretransmit: 0), with data: 154, total data bytes: 8368

Оцените статью
Добавить комментарий

Adblock
detector