SSH 连接故障排查：从 Connection refused 到 Permission denied 的 5 步诊断流程

SSH 连接故障排查：从 Connection refused 到 Permission denied 的 5 步诊断流程

当你在深夜试图通过 SSH 连接到远程服务器部署关键更新时，突然屏幕上跳出冰冷的 "Connection refused" 或 "Permission denied" 错误提示，这种时刻足以让任何运维人员心跳加速。不同于普通的技术问题，SSH 连接故障往往涉及从网络层到应用层的多重因素，需要系统化的排查方法。本文将为你构建一个清晰的诊断决策树，帮助你在最短时间内定位问题根源。

1. 网络层基础检查：确认 SSH 服务的可达性

在遇到 "Connection refused" 错误时，首先需要确认的是：目标服务器是否真的在监听 SSH 连接请求？这个问题看似简单，却经常被忽视。让我们从最基础的网络连通性开始排查。

端口可达性测试是第一步。在客户端执行以下命令可以快速验证目标端口是否开放：

telnet your_server_ip 22

如果连接被立即拒绝（而非超时），通常意味着以下三种情况之一：

• SSH 服务未运行
• 防火墙阻断了连接
• SSH 监听了非标准端口

专业提示：现代 Linux 发行版可能默认未安装 telnet，可以使用nc -zv your_server_ip 22或ssh -v your_server_ip作为替代方案。

服务状态检查需要在服务器端执行。通过以下命令序列可以全面了解 SSH 服务状态：

# 检查服务是否运行 systemctl status sshd # 检查服务是否开机启动 systemctl is-enabled sshd # 检查服务监听端口 ss -tulnp | grep sshd

如果发现服务未运行，启动服务的正确命令是：

sudo systemctl start sshd

防火墙配置是另一个常见瓶颈。不同发行版的防火墙管理工具可能不同，但核心检查思路一致：

# 对于firewalld (RHEL/CentOS) sudo firewall-cmd --list-all | grep ssh # 对于ufw (Ubuntu/Debian) sudo ufw status | grep 22 # 对于iptables sudo iptables -L -n | grep 22

如果发现防火墙规则有问题，临时开放端口的命令示例：

sudo ufw allow 22/tcp

网络拓扑考虑：在云环境或复杂网络架构中，还需要检查：

• 安全组规则（AWS/Azure/阿里云等）
• 负载均衡器配置
• NAT 网关端口映射
• 网络ACL规则

2. 服务配置验证：深入 SSH 守护进程设置

当确认网络层没有问题后，我们需要深入 SSH 服务本身的配置。sshd 的配置文件通常位于/etc/ssh/sshd_config，其中几个关键参数直接影响连接行为：

关键配置参数对照表

修改配置后必须重载服务使变更生效：

sudo systemctl reload sshd

配置检查技巧：

1. 使用sshd -T可以测试当前生效的配置
2. 使用sshd -t可以检查配置文件语法
3. 通过grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"快速查看有效配置

日志分析是定位配置问题的关键。SSH 日志通常位于：

• /var/log/auth.log(Debian/Ubuntu)
• /var/log/secure(RHEL/CentOS)

查看日志的实用命令：

sudo tail -f /var/log/auth.log | grep sshd

典型日志模式分析：

• "Failed password for" → 密码错误
• "Invalid user" → 用户名不存在
• "Connection closed by authenticating user" → 认证成功后断开，可能是shell配置问题

3. 认证问题排查：解决 Permission denied 错误

当看到 "Permission denied" 提示时，说明连接已经到达认证阶段，但验证失败了。这类问题可能涉及多种认证机制，需要系统化排查。

认证失败原因矩阵

密钥认证问题深度排查：

正确的密钥文件权限应该是：

• ~/.ssh 目录：700 (drwx------)
• authorized_keys 文件：600 (-rw-------)
• 私钥文件：600 (-rw-------)

验证命令示例：

ls -ld ~/.ssh ls -l ~/.ssh/authorized_keys

SELinux 相关问题： 如果启用了 SELinux，可能会阻止 SSH 访问关键文件。检查命令：

# 检查SELinux状态 sestatus # 检查相关拒绝日志 sudo ausearch -m avc -ts recent | grep ssh

临时解决方案（不推荐生产环境）：

sudo setenforce 0

永久解决方案：

sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config

PAM 模块限制： 某些系统通过 PAM 模块限制 SSH 访问。检查文件：

• /etc/pam.d/sshd
• /etc/security/access.conf

4. 高级调试技巧：使用 SSH 详细模式

当常规排查无法定位问题时，SSH 的详细输出模式 (-v/-vv/-vvv) 能提供宝贵信息。不同级别的详细程度：

ssh -v user@host # 基本详细 ssh -vv user@host # 更详细 ssh -vvv user@host # 最详细（包括数据包级别）

典型调试输出分析：

1. 连接阶段问题：

debug1: Connecting to host [IP] port 22. ssh: connect to host IP port 22: Connection refused

→ 网络/防火墙/服务未运行问题

2. 密钥交换问题：

debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received

→ 加密算法不匹配，检查/etc/ssh/ssh_config和/etc/ssh/sshd_config的 KexAlgorithms 配置

3. 认证方法问题：

debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey

→ 服务器仅接受密钥认证，但客户端未提供有效密钥

数据包捕获： 在极端情况下，可以使用 tcpdump 捕获 SSH 流量分析：

sudo tcpdump -i eth0 -w ssh.pcap port 22

5. 安全加固与预防措施

解决问题后，应该实施预防措施避免问题再次发生。以下是推荐的 SSH 安全实践：

基础安全加固清单：

• [ ] 修改默认 SSH 端口
• [ ] 禁用 root 直接登录
• [ ] 禁用密码认证，强制使用密钥
• [ ] 设置登录用户白名单
• [ ] 配置 fail2ban 防止暴力破解
• [ ] 定期轮换 SSH 密钥

自动化监控方案：

1. 服务存活监控：

#!/bin/bash if ! systemctl is-active --quiet sshd; then systemctl restart sshd echo "SSH service restarted" | mail -s "SSH Alert" admin@example.com fi

2. 登录失败报警：

# 添加到 /etc/fail2ban/filter.d/sshd.conf failregex = ^%(__prefix_line)s(?:error: PAM: )?Authentication failure for .* from <HOST>

3. 配置备份：

# 每天备份SSH配置 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)

连接问题快速参考指南：

记住，每次修改配置后，使用sshd -t测试语法，然后systemctl reload sshd应用变更。保持配置文档化，建立标准操作流程，这些实践能显著减少未来SSH连接问题的排查时间。