为什么修改端口号后仍可保持连接？

This topic created in 2923 days ago, the information mentioned may be changed or developed.

一台服务器仅开放 22 端口，屏蔽其他所有端口的访问权限
通过 ssh ip:22 登录该服务器，修改 /etc/ssh/sshd_config 将 ssh 端口号改为例如 1234
保存后重启 ssh 执行 /etc/init.d/ssh restart

此时通过 netstat 查看 22 端口已经没有了监听，ssh 端口成功改为了 1234

但神奇的是此时与服务器仍然保持着连接，只要不 exit，那么这个 ssh 客户端是一直可用的

但是一旦 exit 后，无法再次通过 1234 或者 22 端口连接服务器

好奇的是为什么在修改端口号并且 22 端口已经没有了监听的情况下，没有退出的那个客户端仍然可以与服务器通信
因为 22 端口已没有了监听，其他端口都由防火墙屏蔽了，那这个通信是如何进行的？

Supplement 1 · May 29, 2018

实际上条件中："服务器端屏蔽除了 22 之外的所有端口" 如果更换为
通过端口映射连接的内网机器，也同样有这个问题，

比如在有公网 IP 路由器的路由器上，映射路由上一个端口（例如 888 ）至内网的一台机器 22 端口，
那么 SSH 公网 IP:888 连接这台内网机器，此时我在 SSH 中把该机器 SSH 端口改为 1234 并重启 SSH，在 22 端口失去监听的时候，仍然可以进行 SSH 操作，只要不 exit。

这就很奇怪，好奇此时客户端是如何与这台内网机器通信的。

ssh

端口

服务器

exit

31 replies • 2018-05-30 13:25:50 +08:00

1daydayde

May 29, 2018 via iPhone

长链接没释放，或许就是这个设定。万一你改错了然后断开了那岂不是永远连不上了？
坐等楼下专业的说明😂

princeofwales

May 29, 2018

监听的端口就是提供个入口
连接已经建立了，还要监听何用

snnn

May 29, 2018

嗯，是这样的。
你可以强行把所有 ssh 的进程杀掉，以及它们的子进程。
不过如果是我，我选 reboot。

ThirdFlame

May 29, 2018

kill -9 -1
已经建立的连接保持不动，这时候可以试试 1234 能不能连上了。要是连不上，而且你还断开了，那欢迎你用远程控制台或者跑现场吧。

hilow

May 29, 2018 via Android

ssh 使用 tcp 协议，可以了解一下 tcp 连接简历的过程就容易理解了。

server 调用 listen 监听 22 端口的请求
client 调用 connect 连接到 22 端口，此时 client 自动分配一个 port1
server 调用 accept 接受 client 的连接请求，此时 server 自动分配一个新的 port2

所以更改 ssh 的 listen port 是，对上面已经建立的连接 clientIP:port1<------>serverIP:port2
是没有影响的

nikoo

May 29, 2018

@hilow 谢谢回复，但问题是 server 屏蔽了除了 22 之外的所有端口连接，那么理论上 serverIP:port2 是不可能与 client 通信的，这个怎么理解呢？

nikoo

May 29, 2018

@0312birdzhang @princeofwales 这个“长连接”是如何，通过什么方式（ or 端口）与服务器建立的连接？（在服务器端屏蔽除了 22 之外的所有端口的前提条件下）

hilow

May 29, 2018 via Android

你的问题是 server 端的 port2 是被禁止访问的，为什么 clientIP:port1<------>serverIP:port2 之间能通信？

这个我也得查资料确认下，猜测是因为防火墙禁止的只是发送到非 22 端口的 syn 数据包吧。
我这就确认下去

hilow

May 29, 2018 via Android

我说的有些地方不准确。晚上有空我再补充下。
抱歉

mario85

May 29, 2018 via Android

https://unix.stackexchange.com/questions/27636/how-does-ssh-connection-survive-a-network-restart

nikoo

May 29, 2018

@hilow 谢谢，实际上条件中："服务器端屏蔽除了 22 之外的所有端口" 如果更换为
通过端口映射连接的内网机器，也同样有这个问题，

比如在有公网 IP 路由器的路由器上，映射路由上一个端口（例如 888 ）至内网的一台机器 22 端口，
那么 SSH 公网 IP:888 连接这台内网机器，此时我在 SSH 中把该机器 SSH 端口改为 1234 并重启 SSH，在 22 端口失去监听的时候，仍然可以进行 SSH 操作，只要不 exit。

这就很奇怪，好奇此时客户端是如何与这台内网机器通信的。

zst

May 29, 2018 via Android

是不是防火墙放行了 established 状态的包

msg7086

May 29, 2018

监听影响的是新连接。已经建立的连接是不受监听影响的。

我们举个栗子好了。
比如你有 SSH-Server (PID=1000)，监听 IP1 端口 22。
现在你用 SSH 客户端从 IP2 连上去 22 端口，这会发生什么事呢。
1. SSH-Server 接受了你的连接 (IP2 49123 IP1 22)；
2. SSH-Server 叉出一个新进程 SSH-Conn (PID=1096)；
3. SSH-Conn 接管 (IP2 49123 IP1 22) 连接，开始产生 SSH 通信；
4. SSH-Server 继续摸鱼，等待下一个连接。

现在你更改端口为 1234 并重启 SSH 以后，会发生什么事呢。
1. SSH-Server 被谋杀；
2. SSH-Conn 苟且偷生，继续 SSH 通信；
3. SSH-Server 被复活 (PID=1140)，监听 IP1 端口 1234。

至于为什么还能进行 SSH 操作，当然是因为
1. (IP2 49123 IP1 22) 这个连接还活着；
2. SSH-Conn (PID=1096) 这个进程还活着。

Tink

PRO

May 29, 2018

你已经建立的连接没有影响

linyinma

May 29, 2018

看了半天都没有一个回答对涉及两个知识点：

刚开始 SSHD 进程 22 端口处于 LISTENING 状态，你 ssh 连接中完成 accept 后内核生产新的 socket fd 完成 5 元组绑定{ 协议，目的地址、目的端口，本地地址，本地端口}，此过程本地地址端口被复用（ SO_REUSEADDR ），并且 SSHD fork 产生协同进程（ bash,由 /etc/passwd 配置），协同进程继承 SSHD accept 返回的 socket fd ；

在此后的过程中都是和协同进程交换和 SSHD 办毛子关系都没有

nikoo

May 29, 2018

@linyinma 谢谢回复！这个协同进程是如何与服务器进行通信的？

或者换个说法，在 SSH 客户端与服务器成功连接以后，客户端（或服务器）的防火墙如何屏蔽能立刻断开此时的 SSH 客户端与服务器的连接？
再次感谢答疑解惑

xmh51

May 29, 2018

修改 ssh 端口，和防火墙，还有内网端口映射，没半毛钱关系。单纯修改 ssh 端口生效后，已经建立的连接还是可以用的，新的连接必须连接新的 ssh 端口。你的之所以不能连接是因为虽然 ssh 端口监听了，但是被外部条件阻止了（没配置端口映射，防火墙没放开端口）

nikoo

May 29, 2018

@linyinma 在实际测试里，SSH 登录并将端口 22 改为 1234 后，再在 22 端口开一个 nginx，并确定 22 端口已经是 nginx 的监听了，但此时 SSH 仍然与服务器连接的好好的

xmh51

May 29, 2018

你这个是把两个事混在一起看了，应该分开看。

nikoo

May 29, 2018

@xmh51 谢谢回复，问题是已经建立的 SSH 连接客户端与服务器之间是如何通信的？（通过什么方式通信的）

nikoo

May 29, 2018

也就是一台屏蔽了所有端口仅开放 22 端口的服务器，
SSH 登录上去把 22 端口改到 1234 并且在原 22 端口开一个 nginx，
那么目前这台服务器理论上已和外接彻底隔绝了，用浏览器访问 22 端口也是 nginx 的页面了，
那么为什么没有断开的 ssh 客户端仍然可以操作这台服务器，
这个没有断开的客户端是通过什么方式与服务器进行通信的？

xmh51

May 29, 2018

@nikoo 这个还真没深究过，先点个收藏，找到原理了回复下。

wly19960911

May 29, 2018

[root@xxxxxxxxxxxx]~# netstat -ano|grep ':22'
tcp 0 0 172.19.113.74:22 00.000.00.00:44947 ESTABLISHED keepalive (6983.97/0/0)

刚刚检查了下，连接没有建立在 localhost 上，建立在内网的 ip 可以解释为什么 ssh-server 没有绑定在 22 端口上但是仍然可以工作。但是至于防火墙的问题我也不懂，抛砖引玉下

hyq

May 29, 2018

我猜是建立连接以后客户端的 ip，端口，服务器 ip，端口这四个属性就被关联起来，操作系统根据这个把包发给对应的进程 /文件描述符

qbqbqbqb

May 30, 2018

关闭监听是不会影响已经建立的连接的。sshd 监听对应的地址端口四元组是(ServerIP:22,0.0.0.0:0)，协同进程建立的连接对应(ServerIP:22,ClientIP:port)，两者是可以区分的，sshd 退出但协同进程仍然存活，监听“(ServerIP:22,0.0.0.0:0)”失效，连接“(ServerIP:22,ClientIP:port)”仍然有效。
你可能是在想象“关闭在 22 端口上的监听”是“把 22 端口堵上”，但实际上 socket 的工作原理不是这样的。

qbqbqbqb

May 30, 2018

ssh 不涉及防火墙屏蔽除 22 以外端口的问题，因为连接也是建立在 22 端口上的。

但是即使要在其它端口上通信而不被防火墙屏蔽也是可能的（比如 FTP 协议就要建立额外的连接），因为 Linux 的 iptables 防火墙可以跟踪连接状态，可以（并且经常会）配置为直接放行已经建立的连接（ ESTABLISHED ）或和某个已经建立的连接相关的连接（ RELATED，Linux 内核里有针对已知协议专门编写的模块判断数据包是否属于这个状态）。

hilow

May 30, 2018 via Android

server 调用 listen 监听 22 端口的请求
client 调用 connect 连接到 22 端口，此时 client 自动分配一个 port1，并向 server 发送一个 syn 包，表示请求建立新的连接

server 收到 syn 后，调用 accept 接受 client 的连接请求，并向 client 回复一个 syn+ack 包
client 回复 ack 包后，连接正式建立完毕。后续双方发送 psh/ack 包交换数据。直到出现 fin 或 rst 包时，或者连接之间长时间无数据传递，即超时，连接才会关闭。

题目所说防火墙禁用非 22 端口的数据，我猜很大可能，仅仅是允许 22 端口收到 syn 包，建立连接，非 22 端口收到 syn 会被防火墙丢弃。
这个需要你来确认，具体使用的什么防火墙，配置的什么策略。

所以能导致当前 ssh 连接失效断开的情况，有以下几种，
1.sshd 进程关闭，导致 client 收到 fin 或者 rst 包
2.防火墙丢弃 22 端口收到的 psh 或 ack 数据

mario85 所贴链接说明，不会出现第 1 种情况，因为每个已建立的连接是新的进程。ssh 代码应该做了特殊处理，以保证不在重启配置时关闭之前启动的进程。
第二种情况也没有出现，因为防火墙的配置中允许所有端口的 push/ack 包，禁止非 22 端口的 syn 包。

tcp 连接建立过程
https://en.m.wikiversity.org/wiki/Wireshark/TCP

ssh 重启过程，链接由 mario85 提供
https://unix.stackexchange.com/questions/27636/how-does-ssh-connection-survive-a-network-restart

iptables 防火墙使用
https://www.digitalocean.com/community/tutorials/iptables-essentials-common-firewall-rules-and-commands

Allow All Incoming SSH To allow all incoming SSH connections run these commands:

sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT
The second command, which allows the outgoing traffic of established SSH connections, is only necessary if the OUTPUT policy is not set to ACCEPT.

GuuJiang

May 30, 2018 via iPhone

有一家大宝剑开在表♂世界 22 号
楼主想要放♂松一下的时候就进入 22 号
大宝剑为楼主分配了一个伺♂服♂器并且进入里♂世界 22 号
一分钟以后由于外面风声紧，大宝剑只能搬到了表♂世界 1234 号
后面的人想要放♂松只能到 1234 号，而楼主依然留在里♂世界 22 号不受影响
三分钟以后楼主离开了里♂世界 22 号，下次还想再来就只能到 1234 号了

linyinma

May 30, 2018

@nikoo Q1：也就是一台屏蔽了所有端口仅开放 22 端口的服务器，
SSH 登录上去把 22 端口改到 1234 并且在原 22 端口开一个 nginx，
那么目前这台服务器理论上已和外接彻底隔绝了，用浏览器访问 22 端口也是 nginx 的页面了，
那么为什么没有断开的 ssh 客户端仍然可以操作这台服务器，
这个没有断开的客户端是通过什么方式与服务器进行通信的？

A1：我不是回答的嘛，socket 通讯 sfd 绑定的一个 5 元组，为什么能绑定成功后因为地址和端口被复用，你还在纠结“ SSH 登录上去把 22 端口改到 1234 并且在原 22 端口开一个 nginx ” ，这会 nginx server 那个 socket fd 在内核中只是一个三元组，不影响原先通信；

Q2：你希望修改 sshd 监听端口后，能关闭已连接的客户端，说白了就要在内核层面修改状态，从用户层面么 kill 该链接对应的进程，发生中断

Tyanboot

PRO

May 30, 2018

#5 已经明确的跟你说了建立的连接服务端用的都是新端口了, 你为啥还纠结通过什么方式通信的?

就算你把 22 改成 nginx, 和 nginx 也没半毛钱关系.

至于为什么"防火墙关闭除 22 之外的端口之外还能访问", 这应该是你防火墙还有放行 established 状态的规则. 因为我很久以前就试过 iptables -F 之后只加一个 22 端口 accept 的规则. 再用-P DROP 设置默认规则之后. 当前的 ssh 链接立马就被中断了.

hilow

May 30, 2018 via Android

@Tyanboot 我在#5 说的不对。服务端是用 22 端口建立的连接。
#27 是我更正后的准确说明