按理说，

这件看似简单的“改 SSH 端口”操作。却常常让运维人员踩雷，公网 VPS 的 SSH 接口天天被扫。想把 sshd 挪到一个高位端口来降低 auth 日志噪音，却不小心把自己锁在外面。下面我把两次失误的复盘整理出来帮助你在改动前先做个“风险预演”。

再看第一次翻车，改了 Port，端口纹丝不动

我按教科书操作：

# /etc/ssh/sshd_config
Port 
PasswordAuntication no

再看接下来执行。

# systemctl reload sshd
# vim ~/.ssh/config # 把 Port 改成 
# cloud security group 放行 
$ ssh myserver: # Connection refused

Connection refused 和 timeout 是两种完全不同的故障。 “refused”说明 TCP 包已经抵达主机，但没有服务监听；“timeout”则是包被防火墙或安全组丢弃。说起来，于是我先用 nc 确认：

$ nc -zv . .
nc这方面。connect ... port failed: Connection refused
$ nc -zv . 
Connection to . port succeeded!

旧端口还活着，可以登录确认问题。

sshd 说它在听，内核说它在听

登录后检查配置与实际监听：

$ sshd -T | grep ^port
port 
$ ss -tlnp | grep sshd
LISTEN .: users:) #?，?LISTEN : users:)

注意最终一行显示监听 fd 的持有者是 systemd。这是因为 Ubuntu 从某个版本开始默认使用 systemd socket activation；监听 socket 由 systemd 单元 ssh.socket 创建并交给 sshd，而不是直接由 sshd 听。这代表着对 sshd_config 中的 Port 没有任何作用。

要判断是否启用了 socket activation，只需执行：

$ systemctl is-enabled ssh.socket
enabled # 如果是 enabled。你改 Port 就是白改

对了我还发现密码验证没有生效。原因是 OpenSSH 的首值生效规则：主配置文件中包含了 "Include /etc/ssh/sshd_config.d/*.conf";cloud-init 自动生成的配置文件里将 PasswordAuntication 设置为 yes。在我的 no 前面优先解析，从而导致密码登录仍然开启。不过，

使用者痛点一的观点是，配置文件不唯一。生效值难以预测

"我设了"，但真正生效的是所有 include 的合并结果。除非你查看 sshd -T,否则根本无法知道最终取值。

第二次翻车的观点是，自信地写下埋葬自己的四行配置

意识到需要修改 socket 单元。于是创建 drop‑in 文件：

# /etc/systemd/system/ssh.socket.d/listen.conf
ListenStream=
ListenStream=:8080 # 清空原有列表
ListenStream=:
ListenStream=:

执行 reload 与 restart 后再查看：

$ ss -tln | grep :
LISTEN :
LISTEN :

只是当我尝试连接时还是出现 Connection refused。原因是程序只创建了 IPv6 通配 socket，而 IPv4 流量未被映射。原来的 socked 单元里包含独立 IPv4 socket，我无意间把它抹掉了。

至于使用者痛点二，socket 配置易失去 IPv4 支持导致连通性丢失

• 声明 ListenStream 时必须显式写出 IPv4 和 IPv6 两条记录；仅用纯数字或通配符会导致只有一方可用。
• restart 后旧会话不会被强制断开。你看到的状态可能来自旧连接，而非新监听状态。
• 验证一定要使用全新的连接，不能仅凭旧会话中的 ss 输出判断。

门外的人这方面。盘点自己的口袋

被锁在外面时一定要先确认至少还有一种不依赖 SSH 的登录方式，例如云厂商提供的 VNC、web 控制台或 API 控制台。如果没有，可考虑提前打开一个备用 VPN 或远程桌面通道，以防万一。说起来，

`

通道检测结果
80 通道正常？	结果说明
✓	机器和反代都活着，只是 SSH 锁住了内网穿透网关预留的 raw TCP 入口通道。理论上可以通过管理面板建立资源代理回到 .:,从旁门进入——差点用云厂商自动化助手 做这件事。但本机没配 CLI 凭据，IPv6 方法不可用，只能借助云厂商网页 VNC 正解。话说回来，

使用者痛点三这方面。缺少带外控制台导致锁机无救方案

• 如果机器没有 VNC 或 web 控制台，一旦锁机就只能等待管理员介入或重装程序，这往往耗费大量时间与成本。
• 建议预先设置一个独立管理网络或利用云厂商提供的 API 管理接口，以免陷入无路可退局面。
• 修复完成后请务必关闭旧端口，否则安全风险持续存在。

最终版脚本

1. AWS / GCP 等云网站请确保安全组已放行 NEWPORT 并可通过 VNC 登录.
   • MUST: create drop‑in file  /etc/systemd/system/ssh.socket.d/listen.conf

• Create directory if missing:
bash mkdir -p /etc/systemd/system/ssh.socket.d

Create drop‑in file with explicit v4/v6 entries:

bash cat> /etc/systemd/system/ssh.socket.d/listen.conf <'EOF' ListenStream= # clear previous list ListenStream=.:8080 # old port placeholder ListenStream=:${NEWPORT} ListenStream=:${NEWPORT} EOF The : before ${NEWPORT} ensures a wildcard IPv4 address. The entry guarantees IPv6 listening. If you need both ports active。keep old line.

systemctl daemon-reload && systemctl restart ssh.socket -- reloads socket unit and restarts any running service.

sshd -T | grep ^port – verify effective port setting.

systemctl is-enabled ssh.socket – confirm socket activation.

• If you still want PasswordAuntication no,patch cloud‑init config: bash sed -i 's/^#\?PasswordAuntication .*/PasswordAuntication no/' \ /etc/ssh/sshd_config

printf 'PasswordAuntication no '> \ /etc/ssh/sshd_config.d/-cloud-init.conf

This fragment will be read after main config and before or fragments,ensuring your choice takes precedence.

• Verify new connection works: bash nc -zv ${SERVER_IP} ${NEWPORT} && echo 'OK' or try ssh ${USER}@${SERVER_IP} -oPort=${NEWPORT}.

• Finally disable old port once you’re sure everything works: bash systemctl stop ssh.service # stop service listening on old port sed -i '/^Port/d' /etc/ssh/sshd_config systemctl daemon-reload && systemctl restart ssh.service

BOTTOM LINE:

Avoid relying on default Port value when using systemd socket activation.

Add both :${PORT} and :${PORT} lines if you care about dual stack connectivity.

You can’t trust what you edit in /etc/ssh/*;always confirm with sshd -T and ss. They may disagree.

Connection refused means “no listener”,while timeout means “packet dropped by firewall”. Check m separately.

A restart doesn’t tear down existing connections – test with fresh connections only.

Avoid lockouts by keeping a non‑SSH channel open before making changes.

• A successful migration follows this order:

• Sg open new port → dual ports running → validate new connection → client switch → disable old port.

Remember se lessons next time you move your SSH endpoint—your time will thank you.

---