Linux 服务器 SSH 连接被拒的 5 种排查方法

你刚买完一台 Linux VPS，或者半夜收到监控告警说 SSH 登不进去了。终端里一行 ssh: connect to host … port 22: Connection refused，心跳立刻加快。更糟的是：你手头没有 VNC、没有云厂商网页终端，只能对着黑屏干瞪眼。

这类问题我们每个月都会遇到几次——有时是新人改完 sshd_config 忘了重载，有时是安全组只放了 80/443 忘了 22，还有时是 fail2ban 把你家宽带的 IP 封了。好消息是：SSH 连接被拒通常有迹可循，不需要玄学。本文把实战里最高频的五种排查路径整理成清单，按「先读报错、再分层」的顺序走，大多数情况二十分钟内能定位根因。

前提说明：下文默认你有一台还能登录的备用通道（云控制台 VNC、串口、或另一台同 VPC 内网机器）。如果完全失联，请直接跳到文末「彻底失联时怎么办」。

排障前必做：三种「连不上」不是一回事

很多人把 Connection refused、Connection timed out 和 Permission denied 混为一谈，排查方向就完全错了。根据 OpenSSH 官方文档 的语义，这三者分别指向不同层级：

方法一：确认 IP、DNS 与端口可达（网络层）

在怀疑 sshd 之前，先证明「路是通的」。新购 VPS 最常见的问题是：复制错了 IP、域名还没解析生效、或者 SSH 其实监听在非 22 端口而你仍用默认端口连接。

在本地电脑上依次执行：

# 1. 确认解析到的 IP 是否正确
dig +short your.domain.com
ping -c 3 your.server.ip

# 2. 探测 SSH 端口是否开放（把 22 换成你实际端口）
nc -zv your.server.ip 22
# 或
telnet your.server.ip 22

# 3. 指定端口连接（避免 ~/.ssh/config 干扰）
ssh -p 22 -i ~/.ssh/id_ed25519 user@your.server.ip

如果 nc 返回 Connection refused，说明包已经到达服务器——问题在本机服务或本机防火墙，继续方法二。如果 timed out 或一直 hanging，优先查云厂商安全组 / Network ACL：入站规则是否放行 TCP 22（或你的自定义端口），来源是 0.0.0.0/0 还是误设成了内网段。

另外检查本地网络：公司 VPN、校园网、某些地区运营商会屏蔽 22 端口。可临时把 sshd 改到 443 或 2222 做对比测试——若换端口能连上，根因就在路径上的过滤策略，而非服务器本身。

方法二：检查 sshd 服务是否在运行

Connection refused 最高频的根因之一：sshd 根本没起来，或者升级系统后服务名变了。Ubuntu/Debian 上服务名通常是 ssh，RHEL/CentOS 系是 sshd，别猜，用命令确认。

通过 VNC 或云控制台登录后执行：

# Debian/Ubuntu
sudo systemctl status ssh
sudo systemctl start ssh
sudo systemctl enable ssh

# RHEL/CentOS/Rocky
sudo systemctl status sshd
sudo systemctl start sshd

# 是否在监听？监听哪个地址和端口？
sudo ss -tlnp | grep ssh
# 期望看到 0.0.0.0:22 或 [::]:22

# 配置语法检查（改配置后必跑）
sudo sshd -t
sudo systemctl reload ssh   # 或 sshd

若 systemctl status 显示 failed，立刻看日志：sudo journalctl -u ssh -n 50 --no-pager。常见致命错误包括：配置文件拼写错误、指定的 HostKey 文件不存在、ListenAddress 绑在了错误的网卡上。修完配置务必先 sshd -t 再 reload——我们见过太多人改完直接 reload，结果 sshd 起不来，把自己锁在门外。

若服务器刚重装过系统，确认 openssh-server 已安装：sudo apt install openssh-server（Debian 系）或 sudo dnf install openssh-server（RHEL 系）。最小化镜像有时默认不带 SSH 服务端。

方法三：排查本机防火墙与云安全组

sshd 正常运行、ss 也能看到监听，但外面仍 refused——下一嫌疑是防火墙规则把包丢了或拒绝了。Linux 服务器上通常叠了两层：云厂商安全组（网卡外侧）+ 系统内 ufw/iptables/nftables（网卡内侧）。两层都要放行。

系统内常用检查命令：

sudo ufw status verbose
sudo ufw allow 22/tcp
sudo ufw allow 2222/tcp   # 若改了端口
sudo ufw reload

# firewalld（CentOS 等）
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

# 直接看 nftables/iptables
sudo iptables -L INPUT -n -v

云安全组要在控制台改，SSH 进不去时只能走网页。规则注意三点：协议选 TCP、端口范围包含你的 SSH 端口、来源 IP 不要误设成只有某台内网机器。测试阶段可临时放宽为 0.0.0.0/0，确认能连后再收紧到办公室出口 IP。

若你在 VPS 上跑了 Docker 或 Kubernetes，iptables 规则可能被自动改写。此时用 sudo iptables-save | grep 22 看是否有 DROP/REJECT 插在 ACCEPT 前面。关于最小暴露面与 SSH/HTTPS 端口取舍，可参考我们的 Linux 云主机最小暴露面防火墙决策 FAQ。

方法四：核对端口与 sshd_config 配置

为了安全很多人会把 SSH 改到非标准端口，或者限制 ListenAddress 只监听内网。若客户端仍连 22，就会 refused。服务端配置文件一般在 /etc/ssh/sshd_config，关键项如下（完整说明见 sshd_config 手册页）：

Port 2222
# ListenAddress 0.0.0.0   # 默认监听所有网卡；若写成 127.0.0.1 则外网无法连
PermitRootLogin prohibit-password
PasswordAuthentication no
AllowUsers deploy admin

改端口的标准流程：先在新端口上确认监听成功，再改防火墙，最后才关旧端口。切忌一步到位——我们见过太多「把 22 改成 2222 并立刻关闭 22 安全组」的操作，结果新端口还没验证就失联。

另外注意 SELinux（RHEL 系）：若启用，改端口后需执行 sudo semanage port -a -t ssh_port_t -p tcp 2222，否则 sshd 可能启动失败。AppArmor（Ubuntu）也可能限制路径，日志里会有明确提示。

客户端侧核对 ~/.ssh/config 是否写了错误的 Port 或 HostName。多人协作时，有人用别名 Host prod 连生产，复制命令时漏了 -p 也是高发失误。

方法五：排查 IP 封禁（fail2ban / hosts.deny）

如果你收到的是 Permission denied 而非 refused，但确信密钥没问题，要怀疑 IP 被拉黑。fail2ban 会在多次密码错误或异常握手后，自动往 iptables 或 hosts.deny 里写入封禁规则。官方 Wiki 对 jail 机制有详细说明，见 fail2ban 文档。

在服务器上检查：

# fail2ban 状态
sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip YOUR.CLIENT.IP

# 传统 hosts 封禁
grep -v '^#' /etc/hosts.deny
grep -v '^#' /etc/hosts.allow

# 云厂商「运维锁」或 DDoS 清洗
# → 登录云控制台查看是否有安全告警、IP 被临时封锁

自己把自己封了并不罕见：脚本错误导致短时间内大量失败登录，fail2ban 把办公室出口 IP 送进 jail。解封后建议把管理员 IP 加入 ignoreip，或改用密钥登录并关闭密码认证，从源头减少误封。

若你混用 Jenkins、GitLab Runner 等需要回连 VPS 的服务，Agent 注册失败有时也会表现为 SSH 异常。混合拓扑下 Controller 与 Agent 的网络路径值得单独梳理，可参考 Jenkins 混合拓扑：Controller 驻 VPS 与云 Mac Agent 的 JNLP 回连清单。

彻底失联时：别硬扛，走救援通道

如果上述五步仍无法恢复，按优先级尝试：

• 云厂商 VNC / 串口控制台——不依赖 SSH，直接登录修配置
• 快照回滚——改配置前若打过快照，恢复比通宵排障划算
• 单用户模式 / Rescue 盘——挂载原磁盘 chroot 进去改 sshd_config
• 提工单——部分厂商可临时开放端口或解除封锁

教训只有一条：永远不要在唯一的 SSH 会话里做「可能断联」的改动。开第二个终端保持连接，或用 tmux，改防火墙和 sshd 配置时尤其如此。

预防清单：下次少踩坑

排障结束后，花十分钟做收尾，比下次再慌一轮值得多：

• 密钥登录 + 关闭密码，~/.ssh/authorized_keys 权限设为 600
• SSH 端口可改非标准，但安全组与 sshd_config 同步改
• fail2ban 配置 ignoreip，避免把自己人封了
• 改配置前 sshd -t；重要变更前打快照
• 监控探针用独立通道（Agent / 内网），别只靠 SSH 端口探测