CentOS修改SSH默认端口后防火墙未放行，云控制台救场记录

把22换成别的数字，本以为只是改一行配置，结果端口一换，SSH直接失联，云主机像被塞进黑箱。那天我端着咖啡，刷新终端，光标闪半天，心跳也跟着闪——端口没放行，防火墙没开，人还在外网，彻底被挡在门外。下面这条时间线，把踩坑、急救、复盘全写进去，给同样手痒想改默认端口的人留一份“血书”。

改端口前：只改配置就完事？想得美

我图省事，直接vi /etc/ssh/sshd_config，把Port 22改成Port 9222，顺手把ListenAddress 0.0.0.0留那儿，保存退出，systemctl restart sshd，本地ss -tnlp一看9222已经监听，心里还美滋滋：这下扫描器再也找不到我了吧？

结果忘了两条铁律：firewalld没放行9222，云厂商安全组也没放行9222。本地退出当前会话，想重新连，终端直接报Connection refused。再试22，连不上；9222，也连不上。大脑嗡的一声：完，把自己锁外头了。

第一反应：控制台还能进吗？

幸好买的是国内主流云，网页控制台自带VNC。打开浏览器，登录账号，点“远程连接”，弹出黑底绿字，像抓到救命稻草。输入root，密码，成功进系统——云控制台救场第一步达成。

赶紧systemctl status sshd，服务是running，说明配置没错；再firewall-cmd --list-all，public区域里只有22/tcp，9222压根没影。问题定位：防火墙没开洞。

防火墙放行：两条命令的事，顺序不能错

在VNC里敲：

firewall-cmd --permanent --add-port=9222/tcp


firewall-cmd --reload

回显success，心里踏实一半。可还是不敢退出VNC，因为云厂商安全组那边还没动。

云安全组：网页上再开一道门

切回云控制台，找到“安全组”→“配置规则”→“入方向”，点“添加规则”，协议TCP，端口9222，源地址0.0.0.0/0（先放通，后续再收紧），保存。返回本地笔记本，打开新终端：

ssh -p 9222 root@公网IP

第一次握手成功，提示输入密码，登录后看到熟悉的提示符，这才长出一口气——双线放行，端口切换正式生效。

加固：别让救场白忙活

1. 收紧源IP：把安全组0.0.0.0/0改成公司/家庭固定IP段，减少暴露面。

加Fail2ban：yum install fail2ban -y，简单配个[sshd]段落，封爆破IP。

留VNC后门：改完任何远程配置，先别关当前会话，另开窗口验证；实在失手，还能VNC爬回去。

端口复用：若机器跑Nginx，可把9222伪装成https 443，让扫描器误判，降低被盯概率。

踩坑小结：一句话能救命

改SSH端口≠只改sshd_config，防火墙与安全组必须双放行；先留VNC，再关旧门，顺序反了，人就凉了。

常见疑问快答

Q：为什么本地能监听到9222，远程却连不上？

A：监听仅代表进程绑定端口，数据包能否到达进程，要看防火墙、安全组、路由三层是否放通。

Q：云控制台VNC卡顿，有没有别的招？

A：部分云支持“发送远程命令”功能，可在网页直接执行脚本，无需图形界面；若机器装了云助手，也能通过API下发命令开门。

Q：想一次性改完端口、防火墙、安全组，有脚本吗？

A：可写bash，但务必先在测试机跑通；脚本里加sleep与回滚逻辑，一旦失联，让cron定时恢复22端口，给自己留后路。

记录到此，咖啡已经凉透，SSH却稳得一批。下次再动端口，我会先默念：防火墙、安全组、VNC，一个都不能少。