ssh 的端口映射失败，抓了个包，可以看出什么毛病来吗？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

V2EX 提问指南

这是一个创建于 2534 天前的主题，其中的信息可能已经有所发展或是发生改变。

家里的路由器直接拨号连接外部网络，上面配置了 DDNS 和端口映射。在公司 ssh 回去失败.

家里有两台机器，其中一台树莓派，多次尝试后会有一次成功。另外一台 ubuntu，几乎连不上。
树莓派 ssh ubuntu 服务器，没有问题，在家里内网 ssh ubuntu 没有问题。
连不上的表面现象是ssh home.xxx.xxx -p port 后命令一直卡在那里，没有响应，ctrl + c 也不会终止这个命令。
ssh 的时候，我在家里的机器上抓了个包，截图在后面

目前有两个猜想：

梅林路由器固件不稳定导致
有墙

还有其他可能原因吗？

第 1 条附言 · 2017-12-05 20:47:19 +08:00

ssh -vvv 的最后几行结果在此
==================
debug1: channel 1: new [mux-control]
debug3: channel_post_mux_listener: new mux channel 1 fd 3
debug3: mux_master_read_cb: channel 1: hello sent
debug3: mux_master_read_cb: channel 1 packet type 0x00000001 len 4
debug2: process_mux_master_hello: channel 1 slave version 4
debug2: mux_client_hello_exchange: master version 4
debug3: mux_client_forwards: request forwardings: 0 local, 0 remote
debug3: mux_client_request_session: entering
debug3: mux_client_request_alive: entering
debug3: mux_master_read_cb: channel 1 packet type 0x10000004 len 4
debug2: process_mux_alive_check: channel 1: alive check
debug3: mux_client_request_alive: done pid = 68971
debug3: mux_client_request_session: session request sent
debug3: mux_master_read_cb: channel 1 packet type 0x10000002 len 92
debug2: process_mux_new_session: channel 1: request tty 1, X 0, agent 0, subsys 0, term "xterm-256color", cmd "", env 2
debug3: process_mux_new_session: got fds stdin 7, stdout 8, stderr 9
debug1: channel 2: new [client-session]
debug2: process_mux_new_session: channel_new: 2 linked to control channel 1
debug2: channel 2: send open
debug3: send packet: type 90
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: client_session2_setup: id 2
debug2: channel 2: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug1: Sending env LC_ALL = en_US.UTF-8
debug2: channel 2: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 2: request env confirm 0
debug3: send packet: type 98
debug2: channel 2: request shell confirm 1
debug3: send packet: type 98
debug3: mux_session_confirm: sending success reply
debug2: callback done
debug2: channel 2: open confirm rwindow 0 rmax 32768
debug1: mux_client_request_session: master session id: 2

ssh

Ubuntu

家里

映射

5 条回复 • 2017-12-06 11:33:11 +08:00

ybf1220

2017-12-05 20:30:43 +08:00 via iPhone

ssh home.xxx.xxx -p port -vvv 看下调试日志

fzleee

2017-12-05 21:07:32 +08:00

在 ubuntu 的 /etc/ssh/sshd_config 最后添加一行
IPQoS 0x00

问题解决

xustrive

2017-12-06 09:47:38 +08:00

@fzleee IPQoS 0x00 是啥意思百毒没有

fzleee

2017-12-06 10:19:00 +08:00

@xustrive
按照这里的解释，IPQoS 指令用于 IP 层的 type-of-service，默认为“ lowdelay ” 和 "throughput".
http://www.gsp.com/cgi-bin/man.cgi?topic=ssh_config

按照危机百科的介绍，( https://en.wikipedia.org/wiki/Type_of_service)
0x00 指的是设置为 cs0.

为什么修改这两个参数能够解决问题，我也不是很清楚。我是从这里找到的解决方案：
https://github.com/guysoft/OctoPi/issues/294

我的路由器之前 WAN 口双播，不是很稳定。
在添加 IPQoS 0x00 指令前，每次 ssh 都会失败。
在添加 IPQoS 0x00 指令后，每次 ssh 都会成功，但是建立链接花费的时间很长，比如 10 多秒后才成功。
之后我修改 WAN 口单播，ssh 一切正常了。

目前可以理解为路由器的性能在双播情况下处理数据包不稳定导致的 ssh 失败。

xustrive

2017-12-06 11:33:11 +08:00

@fzleee #4 谢谢,以前我也用过双播,使用后感觉反而体验感觉变慢了. 就未再使用过了.~