SSH服务器未应答连接请求

我正在尝试使用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 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 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家用路由器软件并不是真正为处理端口转发而设计的，可怜的人花了一段时间才能实施必要的更改。

但这就像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）。

我已经完成了所有工作……以正确的格式在authorized_keys，chmodding，chowning，重新启动ssh和sshd等中完成了公钥。

对我来说，这是ufw防火墙。完全没有ssh响应提示了我这一点，但是我无法在LAN上双向ping通。

我测试了：

sudo ufw service stop

...而且效果很好，即我从ssh呼叫得到了响应。

因此，再次启动ufw：

sudo ufw service start

...并添加规则：

sudo ufw allow openssh

现在一切正常。

如果您像我一样启用了UFW（在Linux和Ubuntu上），请尝试以下操作：

sudo ufw enable OpenSSH

这将允许防火墙中使用OpenSSH。

只为其他人：

我必须在tcpdump中使用-P选项而不是-Q

tcpdump -i wlan1 port 22 -n -P inout

大多数时候，防火墙是罪魁祸首。做service iptables stop和service ip6tables stop。

如果停止服务不起作用，请执行iptable flush。

iptables --flush.

如果它是虚拟机，那么也要在主机上做同样的事情