2026 年 3 月 27 日补充：
我又改回 22 了，原因是 22 端口属于服务商 QoS 白名单，更换端口反而频繁掉线了……
TLDR
原因：SSH Socket-based activation
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
或
sudo systemctl disable --now ssh.socket
sudo systemctl enable --now ssh.service
sudo systemctl daemon-reload
sudo systemctl restart ssh
排查过程
/etc/ssh 下有两个文件：ssh_config 和 sshd_config
前者负责用 SSH 连接其它服务器时的配置，后者是我们需要修改的配置，它负责告诉当前服务器如何接收和处理外来的 SSH 连接。
像往常一样，修改完sshd_config，接着：
sudo systemctl restart ssh
sudo systemctl restart sshd
sudo ufw allow ${新端口}/tcp
sudo ufw reload
发现依然无法连接，但是还好使用旧端口还是能正常连接。
检查了服务商的防火墙配置也没有问题之后，尝试打印连接信息：
ssh -vvv -p 新端口 user@ip
接着发现开始也很正常，甚至有Connection established信息，然后在最后突然 Connection closed。
进一步查看服务端的日志：
sudo journalctl -u ssh -f
发现监听的端口并没有改变：
Mar 25 08:16:54 VM-8-11-ubuntu systemd[1]: Stopped ssh.service - OpenBSD Secure Shell server.
Mar 25 08:16:54 VM-8-11-ubuntu systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
Mar 25 08:16:54 VM-8-11-ubuntu sshd[3964828]: Server listening on :: port 22.
Mar 25 08:16:54 VM-8-11-ubuntu systemd[1]: Started ssh.service - OpenBSD Secure Shell server.
破案
经过一番搜索，发现了罪魁祸首
简单来说，在较新的 Ubuntu 系统中，为了节省一些内存（约 3 MB），引入了一个新的机制SSH Socket-based activation，sshd 进程不再是持续运行，而是由 systemd 在需要时唤醒，随之而来的变化是，systemd 内部使用了一个配置来管理 sshd 的端口。
所以现在有两种解决方案：
1. 在修改了 sshd_config 之后，还需要将这个配置同步到 systemd 的配置中；
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
- 禁用
SSH Socket-based activation并使用传统的 ssh.service；
sudo systemctl disable --now ssh.socket
sudo systemctl enable --now ssh.service
sudo systemctl daemon-reload
sudo systemctl restart ssh
对我来说，3 MB 内存确实影响不大，所以我果断选择了第二种。
0 条评论