Linux开通SSH服务器端口号的核心操作是：修改sshd_config配置文件、重启ssh服务、放行防火墙端口，这三步缺一不可。
很多人在Linux服务器上折腾SSH端口，要么改了配置连不上，要么防火墙忘了放行，要么SELinux在背后捣乱，这篇文章直接把整个流程拆开揉碎，从检查现状到修改端口，再到防火墙和SELinux的处理，最后给出端口不通时的排查思路,按步骤操作就能搞定。
先确认SSH服务当前状态和端口占用情况
动手修改之前，先搞清楚现状，多数Linux发行版默认安装了OpenSSH服务端，端口是22,用以下命令确认一下：
- 查看SSH服务是否在运行：
systemctl status sshd（CentOS/RHEL系）或systemctl status ssh（Debian/Ubuntu系） - 查看当前监听端口：
ss -tlnp | grep ssh或者netstat -tlnp | grep ssh
如果看到类似 0.0.0:22 的监听记录，说明SSH正在22端口正常服务，如果服务没启动，先执行 systemctl start sshd 或 systemctl start ssh 启动它,再继续后面的操作。
还要确认一下要用的新端口是否被占用，比如想换成22026,就执行：
ss -tlnp | grep 22026
如果有输出，说明这个端口已经被其他进程占用，换个端口号,没输出就可以放心用。
linux修改ssh端口号的标准流程
修改端口的核心操作是编辑SSH配置文件 /etc/ssh/sshd_config，有几种方法,根据使用习惯任选一种。
直接用sed命令修改
最直接的方式是找到 #Port 22 这一行,去掉注释并改成新端口：
sed -i 's/#Port 22/Port 22026/' /etc/ssh/sshd_config
执行后可以用 grep -n "^Port" /etc/ssh/sshd_config 验证修改结果，输出应该是 Port 22026。
安装fail2ban等安全工具的场景
如果服务器装了fail2ban或者其他安全防护软件，修改配置后这些工具可能还盯着旧端口，需要一并调整配置，fail2ban的SSH防护配置通常在 /etc/fail2ban/jail.local，找到 [sshd] 段落，确认没有写死端口,或者相应更新。
无论用哪种方法,修改完后都要检查配置语法：
sshd -t
这条命令会检查配置文件是否有语法错误。没有任何输出就是通过了，如果有报错，根据错误提示回头改配置文件,确认无误后重启服务：
systemctl restart sshd # 或者 systemctl restart ssh
重启后再确认一次监听状态：
ss -tlnp | grep 22026
看到新端口在监听,说明SSH已经切换到新端口了。
防火墙放行新端口的完整操作
改完配置重启了服务，但连不上，绝大多数情况是防火墙拦住了，Linux的防火墙工具主要有firewalld（CentOS 7+、Rocky Linux、AlmaLinux）、ufw（Ubuntu/Debian）、iptables（老版本系统）。
使用firewalld的系统
执行以下命令放行新端口：
firewall-cmd --permanent --add-port=22026/tcp firewall-cmd --reload
第一行添加规则，第二行重新加载让规则生效,验证是否放行成功：
firewall-cmd --list-ports
输出中能看到 22026/tcp 就对了，如果旧端口22不需要了,可以顺手移除：
firewall-cmd --permanent --remove-port=22/tcp firewall-cmd --reload
注意，确认新端口能正常连接后再移除旧端口,避免把自己锁在外面。
使用ufw的系统
Ubuntu/Debian系统通常用ufw管理防火墙：
ufw allow 22026/tcp
查看当前规则确认放行：ufw status，如果ufw处于inactive状态，说明防火墙没启用,这一步可以跳过。
iptables老系统的处理
CentOS 6或更早版本,直接操作iptables：
iptables -A INPUT -p tcp --dport 22026 -j ACCEPT service iptables save iptables -L -n | grep 22026
看到ACCEPT规则即成功。
linux ssh端口修改后SELinux不放行的处理
SELinux是很多Linux管理员修改SSH端口后最头疼的问题，firewalld放行了，端口也监听了，但就是连不上，查看 /var/log/audit/audit.log 发现大量 denied 记录,基本就是SELinux在作怪。
先确认SELinux状态：
getenforce
输出 Enforcing 说明SELinux正在强制模式,查看SSH相关的SELinux端口上下文：
semanage port -l | grep ssh
这一步需要先安装policycoreutils-python-utils工具（CentOS/RHEL系）：
yum install -y policycoreutils-python-utils
Ubuntu/Debian系执行 apt install -y policycoreutils-python3-utils，安装后执行semanage命令，会看到类似 ssh_port_t tcp 22 的输出,把新端口加进去：
semanage port -a -t ssh_port_t -p tcp 22026
再次确认：semanage port -l | grep ssh，看到 22026 在列表中就可以了。
关于SELinux，业内专家指出实际操作中相当一部分SSH连接失败案例的根因都是SELinux端口上下文没有配置,这一点经常被忽视。
云服务器安全组也要放行新端口
如果是在简米云、酷番云、华为云这些国内云厂商的服务器上操作，光改服务器内部还不够，云平台的安全组相当于一层外部的防火墙,需要在控制台配置。
登录云厂商控制台，找到云服务器实例的安全组配置，添加入方向规则，协议选择TCP，端口填写 22026，授权对象根据需求填 0.0.0/0（所有IP）或指定IP段，不同厂商的界面入口略有差异，但逻辑是一样的：找到安全组规则 → 添加规则 → 填端口 → 保存。
这一步不做，即使服务器内部全部配置妥当，新端口依然无法从外部访问，这也是linux 服务器对外开放ssh端口时最容易踩的坑之一。
linux ssh端口不通怎么排查
按照上面步骤操作完后还是连不上，按下述顺序排查,问题基本能定位：
- 第一步：先确认服务端SSH进程是否在监听新端口，用
ss -tlnp | grep 22026，没输出说明服务没起来或配置没生效,回到配置文件检查语法和Port行。 - 第二步：在服务器本机测试，执行
ssh -p 22026 localhost，如果能连上说明SSH服务正常,问题出在网络层。 - 第三步：检查防火墙规则，
iptables -L -n（如果有iptables在运行）或firewall-cmd --list-all,确认新端口在ALLOW列表里。 - 第四步：检查SELinux上下文，
getenforce确认状态，semanage port -l | grep ssh确认端口是否已添加。 - 第五步：从外部机器测试，如果之前用22端口能连，改成新端口后连不上，用
telnet 服务器IP 22026测试端口连通性,连不通就回头检查安全组和防火墙。
还有一个细节：如果之前用密码登录,修改端口后客户端命令需要显式指定新端口：
ssh -p 22026 root@服务器IP
不要忘了 -p 参数，这是linux ssh端口修改后无法连接最常见的人为原因。
Q&A：linux ssh端口相关常见问题
Q1：修改SSH端口后旧端口还能用吗？要不要关闭？
修改配置并重启后，如果新端口正常提供服务，建议关闭旧端口以防止暴力扫描，在防火墙中移除22端口放行规则即可，如果系统防火墙和云安全组都配置了，两处都要移除,先确保新端口稳定连接再执行这一步。
Q2：改SSH端口会影响scp和sftp吗？
会，scp和sftp基于SSH协议，端口修改后，传输命令也要加上对应端口参数，scp的用法是 scp -P 22026 文件 用户名@服务器IP:路径（注意scp是大写的-P，ssh是小写-p），sftp的用法是 sftp -oPort=22026 用户名@服务器IP。
Q3：SELinux直接关闭行不行？
不推荐，关闭SELinux会降低系统整体安全性，尤其对外提供服务的服务器，正确做法是使用 semanage port -a -t ssh_port_t -p tcp 新端口 添加端口上下文，既不影响安全策略，又能让SSH正常运行，如果确实不想用SELinux，建议在开发和测试环境设置 setenforce 0 临时关闭,生产环境保持启用状态。
开通Linux SSH服务器端口号，核心就三件事：改配置文件、重启服务、放行防火墙，加上SELinux和安全组的排查就是完整的闭环，按照本文的顺序操作，linux ssh端口不通的问题多数情况下都能自己解决,以后改端口不会再把自己锁在服务器外面了。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/794547.html
