SSH 服务器不响应连接请求

Question

我正在尝试使用 OpenSSH 在本地计算机上设置 SSH 服务器。当我尝试从远程主机通过 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

Answer 1

一个非常令人失望的自我回答

把这个问题搁置了一天再回到它，我既松了口气又感到不安（比松口气更不安）发现一切都神秘地正常工作。

那么，问题是什么？

没有更改或调整设置——不在路由器上，不在 SSH 服务器上，不在 SSH 客户端的机器上。可以肯定地说，尽管设置正确，但路由器没有正确处理传入的流量。鉴于极小的家用路由器软件并不是真正设计用于处理端口转发，可怜的家伙花了一段时间来实施必要的更改。

但是已经过了 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数据包在它们到达您的服务器之前就被路由器忽略和丢弃。

一旦你发现了问题所在，修复（通常）是微不足道的。