SSH 作为远程管理的核心工具，连接过程中常出现 “Connection refused”“Permission denied” 等报错，新手往往因缺乏系统排查思路陷入困境。本文聚焦 SSH 连接的八大高频疑难问题，从 “现象定位→原因分析→分步解决” 三个维度，提供可落地的排查方案，帮你快速扫清连接障碍，恢复高效运维。

一、问题 1：Connection refused（连接被拒绝）

现象描述

执行 ssh 服务器IP 后，快速返回 ssh: connect to host 服务器IP port 22: Connection refused，无法建立 TCP 连接。

排查步骤与解决方案

1. 确认服务器是否在线

# 测试服务器网络连通性（ping通仅代表网络可达，不代表SSH服务正常） ping 服务器IP

1. 若 ping 失败：检查服务器是否关机、网络是否中断（如云服务器安全组未放通 ICMP 协议），联系机房或云厂商恢复网络。
2. 若 ping 成功：进入下一步排查。

2. 确认 SSH 服务是否正常运行

登录服务器本地（或通过云控制台 VNC），检查 SSH 服务状态：

# CentOS/RHEL systemctl status sshd # Ubuntu/Debian systemctl status ssh

1. 若显示 “inactive (dead)”：SSH 服务未启动，执行 systemctl start sshd 启动，若启动失败，查看日志定位原因（journalctl -u sshd -f）。
2. 若显示 “active (running)”：进入下一步排查。

3. 确认 SSH 端口是否开放

# 服务器本地查看端口监听（以默认22端口为例） ss -tuln | grep 22 # 或 netstat -tuln | grep 22

1. 若无监听记录：修改 SSH 配置文件 /etc/ssh/sshd_config，确认 Port 22 未被注释，重启服务（systemctl restart sshd）。
2. 若有监听记录：进入下一步排查。

4. 确认防火墙 / 安全组是否放通端口

# 检查服务器本地防火墙（以firewalld为例） firewall-cmd --list-ports | grep 22 # 若未放通，执行开放命令 firewall-cmd --permanent --add-port=22/tcp firewall-cmd --reload # 云服务器需额外检查安全组（如AWS Security Group、阿里云安全组） # 确保入方向规则允许“来源IP+22端口”访问

二、问题 2：Permission denied (publickey)（公钥认证失败）

现象描述

使用密钥登录时，提示 Permission denied (publickey)，排除密码登录后仍无法连接。

排查步骤与解决方案

1. 确认客户端使用的密钥是否正确

# 明确指定私钥文件登录，验证密钥是否匹配 ssh -i ~/.ssh/id_ed25519 admin@服务器IP -p 22

1. 若指定正确密钥后登录成功：原因为 SSH 默认加载的密钥与服务器公钥不匹配，需在 ~/.ssh/config 中指定对应密钥（如 IdentityFile ~/.ssh/id_ed25519）。
2. 若仍失败：进入下一步排查。

2. 检查服务器端 authorized_keys 配置

登录服务器，检查公钥文件权限与内容：

# 1. 确认文件权限（必须为600，目录为700） ls -ld ~/.ssh/          # 需为 drwx------ ls -l ~/.ssh/authorized_keys  # 需为 -rw------- # 若权限错误，执行修正 chmod 700 ~/.ssh/ chmod 600 ~/.ssh/authorized_keys # 2. 确认客户端公钥已在authorized_keys中 cat ~/.ssh/authorized_keys | grep "ssh-ed25519"  # 匹配客户端公钥开头 # 若未存在，手动添加客户端公钥（将客户端~/.ssh/id_ed25519.pub内容复制到此处）

3. 检查 SELinux 是否阻止 SSH 读取密钥（CentOS/RHEL 特有）

# 查看SELinux状态 getenforce # 若为Enforcing，检查SSH相关SELinux上下文 ls -Z ~/.ssh/authorized_keys # 正常应为 system_u:object_r:ssh_home_t:s0 # 若上下文错误，执行修复 restorecon -Rv ~/.ssh/

三、问题 3：Host key verification failed（主机密钥验证失败）

现象描述

连接服务器时提示：

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Host key verification failed.

排查步骤与解决方案

1. 确认服务器是否真的变更（如重装系统、更换 IP）

1. 若服务器重装系统 / 更换 SSH 密钥：客户端本地存储的旧主机密钥与新密钥冲突，需删除旧记录。
2. 若服务器未变更：可能遭遇 “中间人攻击”，需联系服务器管理员确认主机密钥是否被篡改。

2. 删除客户端旧主机密钥记录

# 方法1：手动删除known_hosts中对应服务器的记录 vim ~/.ssh/known_hosts # 找到包含“服务器IP”或“服务器域名”的行，删除后保存 # 方法2：使用ssh-keygen自动删除 ssh-keygen -R 服务器IP # 若端口非默认22，需指定端口（如ssh-keygen -R "[服务器IP]:2222"）

3. 重新连接并验证新密钥

ssh admin@服务器IP # 首次连接新密钥时，按提示输入“yes”接受，后续连接不再报错

四、问题 4：Connection timed out（连接超时）

现象描述

执行 ssh 服务器IP 后，长时间等待后返回 ssh: connect to host 服务器IP port 22: Connection timed out。

排查步骤与解决方案

1. 确认服务器 IP 与端口是否正确

1. 检查是否输入错误 IP（如将 192.168.1.101 输为 192.168.1.10），或端口错误（如服务器 SSH 端口为 10022，却用默认 22 端口连接）。
2. 验证端口：telnet 服务器IP 端口 或 nc -zv 服务器IP 端口，若提示 “Connection timed out”，说明端口不可达。

2. 排查网络链路问题

# 客户端 traceroute 跟踪网络链路（Linux/macOS） traceroute 服务器IP # Windows使用 tracert 服务器IP

1. 若某一跳路由超时：可能是中间网络设备（如路由器、防火墙）阻断了连接，联系网络管理员排查链路。
2. 若全程超时：检查服务器是否在局域网内，客户端是否需通过跳板机访问（如跨网段连接需配置 VPN）。

3. 确认服务器是否限制来源 IP

1. 检查服务器防火墙是否仅允许特定 IP 访问：firewall-cmd --list-rich-rules，若存在 IP 白名单，确认客户端 IP 在允许列表中。
2. 云服务器需检查安全组入方向规则，确保客户端公网 IP 在允许范围内。

五、问题 5：SSH 会话频繁断开（闲置超时）

现象描述

SSH 连接后，若闲置几分钟（如不输入命令），会话自动断开，需重新登录。

排查步骤与解决方案

1. 客户端配置会话保持

编辑客户端 ~/.ssh/config，添加心跳包配置：

Host *     # 客户端每60秒发送一次心跳包，避免服务器判定闲置     ServerAliveInterval 60     # 若服务器无响应，最多发送3次心跳包后断开     ServerAliveCountMax 3

1. 效果：配置后，即使闲置 30 分钟，会话仍保持连接。

2. 服务器端配置会话保持（可选）

若客户端无法修改配置，可在服务器 /etc/ssh/sshd_config 中调整：

# 服务器每300秒向客户端发送一次心跳包 ClientAliveInterval 300 # 客户端无响应6次后断开（300*6=1800秒=30分钟） ClientAliveCountMax 6

1. 重启服务生效：systemctl restart sshd。

六、问题 6：Could not resolve hostname（无法解析主机名）

现象描述

执行 ssh web01（使用服务器别名）时，提示 ssh: Could not resolve hostname web01: Name or service not known。

排查步骤与解决方案

1. 确认客户端是否配置别名

# 检查~/.ssh/config是否存在对应别名配置 cat ~/.ssh/config | grep "Host web01"

1. 若未配置：添加别名配置（参考示例）：

Host web01     HostName 192.168.1.101  # 服务器实际IP     User admin     Port 22

1. 若已配置：检查 HostName 是否正确（如 IP 是否输错）。

2. 确认主机名是否能正常解析

# 测试主机名DNS解析 nslookup web01 # 或 ping web01

1. 若解析失败：说明 DNS 服务器无该主机名记录，需在 /etc/hosts 中手动添加映射：

echo "192.168.1.101 web01" >> /etc/hosts

七、问题 7：Permission denied, please try again（密码登录失败）

现象描述

使用密码登录时，多次输入正确密码仍提示 Permission denied, please try again。

排查步骤与解决方案

1. 确认服务器是否启用密码登录

登录服务器本地，检查 SSH 配置：

grep "PasswordAuthentication" /etc/ssh/sshd_config

1. 若显示 PasswordAuthentication no：服务器禁用密码登录，需启用（改为 PasswordAuthentication yes），重启服务（systemctl restart sshd）。
2. 若显示 PasswordAuthentication yes：进入下一步排查。

2. 确认用户密码是否正确

1. 服务器本地执行 passwd 用户名（如 passwd admin），重置用户密码，确保输入的密码与重置后的一致。
2. 注意：Linux 密码区分大小写，避免输入时大小写错误。

3. 检查 PAM 认证是否阻止登录

# 查看PAM配置（/etc/pam.d/sshd） grep "pam_tally2" /etc/pam.d/sshd

1. 若存在 auth required pam_tally2.so 配置：用户可能因登录失败次数过多被锁定，执行 pam_tally2 -u 用户名 -r 解锁（如 pam_tally2 -u admin -r）。

八、问题 8：SSH 命令执行乱码（终端编码异常）

现象描述

SSH 登录服务器后，执行 ls 等命令时，中文文件名显示为乱码（如 “????.txt”），或命令提示符格式错乱。

排查步骤与解决方案

1. 确认服务器端字符编码

# 服务器端查看当前编码 echo $LANG # 正常应为 UTF-8（如 en_US.UTF-8、zh_CN.UTF-8）

1. 若编码非 UTF-8：修改服务器 /etc/locale.conf，设置默认编码：

echo "LANG=en_US.UTF-8" >> /etc/locale.conf source /etc/locale.conf  # 临时生效，重启后永久生效

2. 客户端配置终端编码

1. Windows Git Bash：右键终端→Options→Text→Local，选择 “UTF-8”。
2. Linux/macOS：编辑 ~/.bashrc 或 ~/.zshrc，添加编码配置：

export LANG=en_US.UTF-8 export LC_ALL=en_US.UTF-8

执行 source ~/.bashrc 生效。

3. SSH 连接时指定终端类型

# 连接时指定终端类型为xterm-256color（支持UTF-8编码） ssh -t admin@服务器IP "export TERM=xterm-256color; exec bash"

1. 或在 ~/.ssh/config 中添加 Term xterm-256color，永久生效。

总结：SSH 排查的 “黄金法则”

1. 从网络到应用分层排查：先确认网络连通性（ping / 端口），再检查服务状态（sshd），最后定位认证 / 配置问题，避免跳过基础环节。
2. 善用调试模式：执行 ssh -v 服务器IP（-v 详细模式，-vvv 最详细），查看连接过程日志，关键错误信息（如 “Permission denied” 前的日志）往往能直接定位原因。
3. 记录排查过程：遇到问题时，记录 “现象→执行的命令→输出结果”，便于后续复盘或向他人求助时提供清晰信息。