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

Question

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

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

yoshimi@robots:/$ ssh -vv volt@99.3.26.94
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-сервере, что за хрень еще там ??

РЕДАКТИРОВАТЬ: NetStat Server Output

С сервера SSH:

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

Answer 1

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

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

Итак, в чем была проблема?

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

Но это было как 6 часов!

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

Так как я узнаю, что это моя проблема?

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

tcpdump -i wlan1 port 22 -n -Q inout

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

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

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

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