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-сервере, что за хрень еще там ??

РЕДАКТИРОВАТЬ: запрос на подключение из внутренней сетевой ошибки

yoshimi@robots:/$ ssh volt@192.168.1.90
ssh: connect to host 192.168.1.90 port 22: No route to host

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

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

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

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

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

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

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

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

tcpdump -i wlan1 port 22 -n -Q inout

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

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

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

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

Я бегу Mint (Ubuntu).

Я сделал все ... открытый ключ в правильном формате с авторизованными ключами, chmodding, chowning, перезапуском ssh, sshd и т. Д. Как и везде было задокументировано.

Для меня это был брандмауэр UFW. Отсутствие какого-либо ssh-отклика вообще подтолкнуло меня к этому, но я не мог пропинговать обе проблемы в локальной сети.

Я проверил:

sudo ufw service stop

... и это сработало отлично, т.е. я получил ответ от ssh-вызова.

Итак, запустите UFW снова:

sudo ufw service start

... и добавьте правило:

sudo ufw allow openssh

Теперь все работает нормально.

Если вы, как и я, включили UFW (в Linux, Ubuntu в моем случае), попробуйте следующее:

sudo ufw enable OpenSSH

Это позволит OpenSSH в брандмауэре.

Просто для других:

Мне пришлось использовать опцию -P в tcpdump вместо -Q

tcpdump -i wlan1 port 22 -n -P inout

Большую часть времени брандмауэр является виновником. Есть service iptables stopи service ip6tables stop.

Если остановка службы не работает, тогда выполните iptable flush.

iptables --flush.

Если это виртуальная машина, сделайте то же самое в хосте