我正在尝试使用 OpenSSH 在本地计算机上设置 SSH 服务器。当我尝试从远程主机通过 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 Web 目录。端口 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 网络安装。
那么：还有什么呢？它确实看起来是一种防火墙之类的东西，可以忽略流量，但如果它不是路由器，不是 iptables，也不是 SSH 服务器上的另一个防火墙，...那还有什么呢？
编辑：NetStat 服务器输出
从 SSH 服务器：
tcp6 0 0 :::22 :::* LISTEN 5784/sshd
答案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 种可能性：
- 如果你看到传入来自远程机器的流量，但是没有传出来自本地服务器的流量，问题就出在服务器上：可能需要更改防火墙规则等。
- 如果你看到传入和传出，但您的远程机器没有收到响应，很可能是路由器的问题：它允许传入流量，但丢弃传出的数据包。
- 如果有完全没有交通，这可能也是路由器的问题：远程机器的
SYN数据包在到达您的服务器之前就被路由器忽略和丢弃。
一旦发现了问题所在，修复通常就很容易了。