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

Я пытаюсь настроить 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
Источник

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 пакеты игнорируются и отбрасываются маршрутизатором еще до того, как они достигают вашего сервера.

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

Источник
Другие вопросы по тегам