Ubuntu SSH 改了端口却连不上：被忽略的 socket activation

配置文件显示新端口，实际却没监听

旧排障记录描述了 Ubuntu 24.04 上的一个陷阱：sshd -T 能读到新端口，ss -tlnp 却看不到监听；进一步操作之后，ssh.socket 甚至因 Address already in use 失败。原来的 SSH 会话还在，但新连接进入不了服务器。

关键不在于端口数字，而在于是谁负责监听这个端口。

两份配置都想监听同一个端口

该环境启用了 systemd socket activation。系统的 generator 已经根据 sshd 配置生成了一份 ssh.socket 监听配置；如果又手工创建一个重复的 ListenStream override，就可能让同一个 socket 被定义两遍，最终在绑定时撞上自己。

我因此考虑撤去多余的手工 override，让 generator 保持单一事实来源，再重新加载 systemd 并检查新端口是否确实出现。

为什么我会把“保留旧 SSH 窗口”当作第一步

已有连接不依赖 ssh.socket 再为它创建一次新监听，这给恢复工作留了窗口；一旦把所有会话都关掉，排障就只能依靠带外控制台或其他仍可达的管理通道。

这个案例和“登录阶段被 Fail2ban 误封”表现相似，但不等于同一个根因。Oracle VPS 折腾日记里已经记录了另一次 Fail2ban 问题，排查时必须分别验证监听状态与封禁列表。

这类问题还和 Ubuntu 版本、systemd socket 配置及实际部署方式有关。排查时不能只看配置文件中的端口，还需要核对系统最终监听了什么。