修改 SSH 端口后出现 Permission denied，通常不是端口本身的问题，而是认证配置被联动修改或防火墙/SELinux 拦截导致连接行为异常，优先通过控制台恢复访问再排查。

命令速用版

如果你还能通过其他终端登录服务器，可用以下命令快速检查状态：

# 检查 SSH 服务监听端口
ss -tlnp | grep sshd

# 查看 SSH 配置中的端口设置
grep ^Port /etc/ssh/sshd_config

# 查看认证相关配置
grep -E "PasswordAuthentication|PermitRootLogin" /etc/ssh/sshd_config

# 配置语法检查（修改后必执行）
sshd -t

# 查看实时认证日志（CentOS/RHEL）
tail -f /var/log/secure

# 查看实时认证日志（Ubuntu/Debian）
tail -f /var/log/auth.log

为什么会这样

严格来说，Permission denied 表示 TCP 连接已经建立，但用户名、密码或密钥验证未通过。修改端口本身不会直接导致认证失败，但实际操作中常伴随以下情况：

第一，编辑 /etc/ssh/sshd_config 时，为了改端口可能误触了认证相关选项，例如将 PasswordAuthentication 改为 no 或限制了 PermitRootLogin。

第二，用户混淆了报错信息。如果新端口被防火墙或 SELinux 拦截，客户端通常报 Connection refused 或 Connection timed out，但部分用户会统称为“连不上”或“权限拒绝”。

第三，客户端缓存了旧的主机密钥。更换端口后，本地 known_hosts 可能冲突，导致连接被客户端主动中断，表现为类似权限错误。

分步处理

1. 确保有备用登录方式

在修复 SSH 前，务必确认你能通过云服务商的 VNC 控制台、物理显示器或 IPMI 登录服务器。如果 SSH 彻底无法使用且无控制台权限，修改配置可能导致永久失联。

2. 区分报错类型

在本地终端执行连接命令，观察具体报错：

ssh -v -p <新端口> <用户>@<IP>

如果看到 Connection refused，重点检查防火墙和 SELinux；如果看到 Permission denied (publickey,password)，重点检查认证配置。

3. 检查服务端配置

登录服务器后，检查 /etc/ssh/sshd_config 文件。确认以下参数符合你的预期：

Port <新端口号>
PasswordAuthentication yes
PermitRootLogin yes # 仅排查期间临时开启，修复后建议改为 no

注意：如果只允许密钥登录，请确认本地公钥已正确写入服务端的 ~/.ssh/authorized_keys 且权限正确（目录 700，文件 600）。

重要：修改配置后，务必先执行 sshd -t 检查语法，无输出则表示配置正确，再重启服务。

4. 检查防火墙与安全组

如果是 Connection refused，检查系统防火墙：

# CentOS/RHEL
firewall-cmd `--list-ports`

# Ubuntu/Debian
ufw status

同时检查云厂商控制台的“安全组”规则，确保新端口 TCP 协议已对当前 IP 放行。

5. 检查 SELinux（仅限 CentOS/RHEL）

如果开启 SELinux，默认只允许 SSH 运行在 22 端口。修改端口后需告知 SELinux：

# 查看当前允许的 SSH 端口
semanage port -l | grep ssh

# 添加新端口（例如 2222）
semanage port -a -t ssh_port_t -p tcp 2222

注意：setenforce 0 仅用于临时测试排查，生产环境慎用，排查后请立即恢复为 setenforce 1。

怎么验证是否生效

修改配置后，重启 SSH 服务：

systemctl restart sshd

然后立即在另一个终端窗口尝试连接，不要关闭当前会话，以防新配置有误导致无法登录。使用详细模式查看握手过程：

ssh -v -p <新端口> <用户>@<IP>

如果连接成功，查看服务端日志确认无异常报错。典型 Permission denied 日志示例：

# CentOS/RHEL
grep sshd /var/log/secure | tail -n 20

# Ubuntu/Debian
grep sshd /var/log/auth.log | tail -n 20

# 典型错误日志示例
Failed password for invalid user root from 192.168.1.1 port 2222 ssh2
Authentication refused: bad ownership or modes for file /root/.ssh/authorized_keys

常见坑

1. 配置未保存或语法错误：编辑配置文件后未保存，或存在拼写错误，导致 sshd 服务启动失败。修改前建议备份：cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak。

2. 多 Port 配置冲突：配置文件中可能存在多行 Port 设置，确保只保留了你需要的新端口，或者明确保留了旧端口作为备用。

3. 客户端 known_hosts 冲突：更换端口后，如果 IP 不变，本地可能提示 Host key verification failed。需清理本地缓存：ssh-keygen -R <服务器 IP 地址>。

4. 安全组未同步：系统防火墙放行了，但云厂商控制台的安全组未放行，这是最常见的外部拦截原因。