“Connection refused”表示SSH服务未监听22端口，主因是sshd未运行、配置错误、防火墙拒绝、端口绑定失败或SELinux/AppArmor拦截；需依次检查服务状态、端口监听、防火墙规则、配置语法及安全模块限制。

如果您执行 ssh user@host 后收到 ssh: connect to host xxx port 22: Connection refused 错误，该信号表明 TCP 连接在 SYN 阶段即被目标主机内核主动拒绝，而非网络不可达或认证失败。这通常指向 SSH 守护进程未运行、端口未监听或被本地策略拦截。以下是排查与修复该问题的多种路径：

一、验证 sshd/sshd 服务是否处于活动状态

SSH 连接被拒的最常见原因是守护进程根本未启动，systemd 无法拉起 sshd 实例将导致 22 端口完全不响应任何连接请求。

1、执行 sudo systemctl status ssh（Ubuntu/Debian）或 sudo systemctl status sshd（RHEL/CentOS/Fedora）检查服务当前状态。

2、若输出中显示 inactive (dead) 或 failed，说明服务未运行。

3、运行 sudo systemctl start ssh（或 sudo systemctl start sshd）尝试手动启动。

4、启动成功后，立即执行 sudo systemctl enable ssh（或 sudo systemctl enable sshd）确保开机自启。

二、确认 22 端口是否真实监听

即使服务显示 active (running)，sshd 也可能因配置错误（如 BindAddress 冲突、HostKey 缺失、ListenAddress 设置为非通配地址）而无法绑定端口，此时 netstat/ss 输出中将查不到 :22 的监听项。

1、运行 sudo ss -tlnp | grep ':22' 查看是否有进程监听 22 端口及对应 PID。

2、若无输出，再执行 sudo systemctl restart ssh（或 sudo systemctl restart sshd），并观察重启日志是否报错。

3、若重启失败，立即查看详细错误：运行 sudo journalctl -u ssh --since "1 hour ago" -n 50 -e（Ubuntu）或 sudo journalctl -u sshd --since "1 hour ago" -n 50 -e（RHEL），重点关注配置文件语法错误、密钥加载失败或 bind 失败提示。

三、检查防火墙是否显式拒绝 22 端口入站流量

系统级防火墙（如 ufw、firewalld）可能配置了默认 deny 策略，且未放行 22/tcp，导致内核在连接建立前直接返回 RST 包，现象与服务未运行完全一致。

1、Ubuntu/Debian 用户运行 sudo ufw status verbose，确认状态为 active 且 22/tcp 在 Incoming 规则中显示为 ALLOW。

2、若未允许，执行 sudo ufw allow 22 并再次检查状态。

3、RHEL/CentOS 用户运行 sudo firewall-cmd --list-all，确认 public zone 中包含 ports: 22/tcp；若缺失，执行 sudo firewall-cmd --permanent --add-port=22/tcp 后 sudo firewall-cmd --reload。

四、排查 SSH 配置文件中的致命错误

sshd_config 中存在语法错误、非法指令或路径错误（如指定不存在的 HostKey 文件、无效的 ListenAddress 值）会导致 sshd 启动时静默失败或启动后立即退出，造成“服务看似运行实则未监听”。

1、运行 sudo sshd -t 对配置文件进行语法校验；若返回非零退出码，说明存在错误。

2、若校验失败，执行 sudo sshd -T 查看实际生效的完整配置（含 include 展开），定位异常项。

3、重点检查第 86 行附近（常见出错位置）、Port、ListenAddress、HostKey、PermitRootLogin 等关键指令是否拼写正确、路径可读、值合法。

4、临时注释可疑行后保存，再执行 sudo systemctl restart ssh 测试是否恢复监听。

五、验证是否因 SELinux 或 AppArmor 强制拦截

在启用强制访问控制的系统中，SELinux（RHEL/CentOS）或 AppArmor（Ubuntu/Debian）策略可能阻止 sshd 绑定网络端口或访问密钥文件，导致服务启动但无法提供服务。

1、RHEL/CentOS 用户运行 sudo sestatus，若 State 为 enabled 且 Current mode 为 enforcing，则需进一步检查。

2、执行 sudo ausearch -m avc -ts recent | grep sshd，若输出 AVC denied 日志，说明 SELinux 拦截。

3、Ubuntu 用户运行 sudo aa-status | grep ssh，若显示 sshd 处于 enforce 模式且有拒绝记录，则需调整 profile 或临时设为 complain 模式测试。

4、临时禁用以验证：RHEL 执行 sudo setenforce 0；Ubuntu 执行 sudo systemctl stop apparmor；随后重启 ssh 服务并测试连接。