☰

SSH-сервер не отвечает на запрос на подключение

tag-icon • tag-icon linux networking ssh firewall openssh
SSH-сервер не отвечает на запрос на подключение

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

Вот что происходит, когда я пытаюсь подключиться по SSH с удаленного хоста:

yoshimi@robots:/$ ssh -vv [email protected]
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 99.3.26.94 [99.3.26.94] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 99.3.26.94 port 22: Connection timed out
ssh: connect to host 99.3.26.94 port 22: Connection timed out

Где robotsнаходится мой удаленный хост и 99.3.26.94где находится мой локальный SSH-сервер.

SSH работает

volt@arnold:~$ ps -A | grep sshd
 5784 ?        00:00:00 sshd

Где arnoldнаходится мой локальный SSH-сервер.

На маршрутизаторе настроена переадресация портов

Я настроил свой домашний маршрутизатор на переадресацию портов 80 и 22 на мой SSH-сервер. Интересно, что порт 80 работал без сбоев — напрямую в веб-каталог Apache. Порт 22 — не очень.

NMap сообщает, что данные отфильтрованы

yoshimi@robots:/$ nmap -p 22 99.3.26.94

Starting Nmap 6.47 ( http://nmap.org ) at 2015-06-02 14:45 EDT
Nmap scan report for 99-3-26-94.lightspeed.bcvloh.sbcglobal.net (99.3.26.94)
Host is up (0.33s latency).
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

Где robotsнаходится мой удаленный хост и 99.3.26.94где находится мой локальный SSH-сервер.

Это не IPTables (я думаю)

volt@arnold:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere

...И у меня нет никаких других установленных брандмауэров -- это относительно свежий Debian NetInst.

Итак, тогда:Что еще это может быть?Конечно, это похоже на что-то вроде брандмауэра, который просто игнорирует трафик, но если это не маршрутизатор, не iptables и не еще один брандмауэр на сервере SSH, ...что, черт возьми, там еще есть??

EDIT: Вывод сервера NetStat

С SSH-сервера:

tcp6       0      0 :::22                   :::*                    LISTEN      5784/sshd

решение1

Очень разочаровывающий ответ самому себе

Отложив эту проблему на день и вернувшись к ней, я был одновременно и облегчен, и встревожен (скорее встревожен, чем облегчен), обнаружив, что все, каким-то загадочным образом, работает нормально.

Так в чем же была проблема?

Никакие настройки не были изменены или скорректированы — ни на маршрутизаторе, ни на сервере SSH, ни на машине клиента SSH. Можно с уверенностью сказать, что маршрутизатор не обрабатывал входящий трафик должным образом, несмотря на правильные настройки. Учитывая, что программное обеспечение для маршрутизатора dinky home неДействительноразработанный для работы с переадресацией портов, бедняге потребовалось некоторое время, чтобы внедрить необходимые изменения.

Но прошло уже около 6 часов!!

Да, чувак, я знаю. Я провел весь день, пытаясь понять, что не так, и так и не нашел, потому что тамне былочто-то не так. Очевидно, что может потребоваться 6 часов — возможно, больше — для того, чтобы настройки маршрутизатора вступили в силу.

Как узнать, моя ли это проблема?

Отличный инструмент, на который я наткнулся во время этой авантюры, — это tcpdump. Этот подтянутый малыш обнюхивает трафик для вас, предлагая ценную информацию о том, что на самом деле происходит. Плюс, у него есть некоторые суперфильтрующие функции, которые позволяют вам сузить круг того, что вы хотите посмотреть. Например, команда:

tcpdump -i wlan1 port 22 -n -Q inout

Указывает tcpdumpискать трафик через интерфейс wlan1 ( -i= 'interface'), только через порт 22, игнорировать разрешение имен DNS ( -n= 'no name resolution'), а мы хотим видеть как входящий, так и исходящий трафик ( -Qпринимает in, out, или inout; inoutпо умолчанию).

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

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

И как только вы обнаружите, в чем проблема, ее решение (обычно) будет тривиальным.

Связанный контент