SSH 失败问题 & 解决方案合集

排查思路总览

遵循从简到繁的原则：

1. 检查网络连通性
2. 检查客户端基本输入和配置
3. 检查服务器端SSH服务状态
4. 检查身份认证相关配置
5. 检查服务器端防火墙和安全组
6. 检查服务器端详细日志

---

一、网络连通性问题

问题原因： 客户端根本无法与服务器的SSH端口（默认22）建立TCP连接。

解决方案：

1. 使用 ping 检查基本连通性：

   ping <服务器IP或域名>
   

   • 如果 ping 不通，说明网络层有问题。可能的原因是：
     • 服务器已关机。
     • 客户端与服务器之间的网络路由问题。
     • 服务器防火墙或云服务商的安全组（Security Group）丢弃了所有ICMP包（ping 使用的协议）。这时即使 ping 不通，SSH也可能正常，需要进一步检查端口。

2. 使用 telnet 或 nc 检查SSH端口连通性：

   telnet <服务器IP> 22
   # 或者
   nc -zv <服务器IP> 22
   

   • 连接被拒绝 (Connection refused)： 通常意味着服务器端SSH服务根本没有运行。
   • 连接超时 (Connection timed out)： 通常意味着路径上的防火墙（或云服务商安全组）明确丢弃了发往该端口的包。

---

二、客户端问题

问题原因： 命令、配置或密钥文件错误。

解决方案：

1. 检查命令语法：

   ssh username@hostname -p port_number # 注意：-p 参数指定端口，如果端口是22，可以省略
   

   • 确保用户名、主机IP/域名、端口号正确。端口错误是最常见的疏忽之一。

2. 检查密钥文件权限：

   • SSH对密钥文件的权限要求非常严格。如果权限太开放，它会出于安全原因直接拒绝使用。
   • 修复命令：

     chmod 600 ~/.ssh/id_rsa # 私钥权限应为 600 (rw-------)
     chmod 644 ~/.ssh/id_rsa.pub # 公钥权限应为 644 (rw-r--r--)
     chmod 700 ~/.ssh # 目录本身权限应为 700 (rwx------)
     

3. 检查并指定正确的密钥文件：

   • 如果你使用了非默认名称的密钥（如 id_rsa_work），需要使用 -i 参数指定：

     ssh -i ~/.ssh/id_rsa_work username@hostname
     

4. 检查客户端SSH配置 (~/.ssh/config)：

   • 此文件中的配置可能会覆盖你的命令行参数。检查是否有关于目标主机的不正确配置，例如错误的用户名、端口、密钥路径或代理设置。

5. ** known_hosts 文件冲突**：

   • 如果服务器重装了系统或IP地址分配给了新机器，服务器的指纹会变化，客户端会报错 Host key verification failed。
   • 解决方案： 使用 ssh-keygen -R <hostname或IP> 命令清除旧指纹，然后重新连接接受新指纹。

6. 启用详细模式 (-v)：

   • 这是最强大的调试工具。添加 -v、-vv 甚至 -vvv 参数可以输出非常详细的连接过程信息，帮助你精准定位问题阶段。

   ssh -vvv username@hostname
   

   • 仔细观察输出，它会告诉你连接在哪个步骤失败了（例如：连接建立、密钥交换、认证协商、认证失败）。

---

三、服务器端问题

问题原因： SSH服务未运行、配置错误或拒绝了你的连接请求。

解决方案：
你需要通过其他方式（如云控制台的VNC、物理服务器的直接操作）登录到服务器进行以下检查。

1. 检查SSH服务状态：

   # 对于 Systemd 系统 (Ubuntu 16.04+, CentOS 7+)
   systemctl status sshd    # Ubuntu/Debian
   systemctl status sshd    # CentOS/RHEL/Fedora
   
   # 如果服务未运行，启动它
   sudo systemctl start sshd
   sudo systemctl enable sshd # 设置开机自启
   
   # 对于旧版 SysVinit 系统
   service ssh status
   service ssh start
   

2. 检查SSH服务配置 (/etc/ssh/sshd_config)：

   • 修改配置后需要重启服务：sudo systemctl restart sshd
   • 检查监听端口： Port 22 是否被注释或修改？
   • 检查监听地址： ListenAddress 0.0.0.0 表示监听所有IP。如果被设置为 127.0.0.1，则只能本地连接。
   • 检查是否允许密码登录： PasswordAuthentication yes。如果设置为 no，你必须使用密钥登录。
   • 检查是否允许Root登录： PermitRootLogin yes（或 prohibit-password）。如果设置为 no，则无法直接以root用户登录。
   • 检查用户允许/拒绝列表：
     • AllowUsers user1 user2@specific_ip： 如果设置了，只有列表中的用户/IP能登录。
     • DenyUsers user3： 如果设置了，该用户被明确拒绝。
     • 检查你的用户名是否在不正确的列表中。
   • 检查公钥认证是否开启： PubkeyAuthentication yes。如果设置为 no，则无法使用密钥登录。

3. 检查服务器端防火墙 (Firewall)：

   • CentOS/RHEL/Fedora (firewalld)：

     sudo firewall-cmd --list-all # 查看当前规则
     sudo firewall-cmd --permanent --add-service=ssh # 如果没有放行SSH，添加规则
     sudo firewall-cmd --reload
     

   • Ubuntu/Debian (ufw)：

     sudo ufw status
     sudo ufw allow ssh  # 或 sudo ufw allow 22
     

   • iptables (通用)：

     sudo iptables -L -n # 查看规则
     

4. 检查云服务商安全组 (Security Group)：

   • 这是虚拟云服务器（如AWS、阿里云、腾讯云）最常见的问题之一！
   • 登录云控制台，找到你的实例（虚拟机），检查其安全组规则：
     • 入口规则 (Inbound Rules)： 必须有一条规则允许源（Source）为你的客户端IP（或 0.0.0.0/0 表示所有IP）访问端口 22（或你自定义的SSH端口）。协议通常是TCP。

5. 检查服务器端磁盘空间：

   • 如果磁盘空间已满（df -h），SSH可能无法创建登录会话或记录日志，导致登录失败。

6. 检查服务器端SSH日志：

   • 日志通常位于 /var/log/auth.log (Ubuntu/Debian) 或 /var/log/secure (CentOS/RHEL)。
   • 当客户端尝试连接时，实时查看日志：

     sudo tail -f /var/log/auth.log
     

   • 然后从客户端再次尝试登录，观察服务器日志的输出。日志会明确告诉你拒绝连接的原因，例如：
     • Invalid user username： 用户名错误。
     • Permission denied (publickey)： 密钥认证失败。
     • Accepted password for user： 虽然认证成功了，但后面可能还有别的错误。
     • pam_limits(sshd:session): Could not set limits for session： 可能是磁盘空间已满。

---

四、认证问题

问题原因： 密码错误或公钥未配置。

解决方案：

1. 密码认证失败：

   • 确保密码正确，注意大小写。
   • 如果忘了密码，需要通过其他方式登录服务器后使用 passwd 命令重置。

2. 公钥认证失败：

   • 确保公钥已正确添加到服务器对应用户的 ~/.ssh/authorized_keys 文件中。
   • 检查 authorized_keys 文件权限（应为 600 或 644）。
   • 检查 ~/.ssh 目录权限（应为 700）。
   • 确保公钥内容是一行完整的文字，没有换行或多余字符。

总结与排查流程图

当你遇到SSH登录失败时，可以按以下顺序排查：

遵循这个流程，绝大多数SSH登录问题都能被定位和解决。其中，ssh -vvv 和 服务器端日志 是你最重要的两个诊断工具。