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

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

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

[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 端口上但是仍然可以工作。但是至于防火墙的问题我也不懂，抛砖引玉下

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

关闭监听是不会影响已经建立的连接的。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 的工作原理不是这样的。

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

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

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.

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

@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 该链接对应的进程，发生中断

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

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

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

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