ssh 连接报错的错误解决排查记录

Authentication Rejected 错误解决方案

即使使用密码验证仍出现 “Authentication Rejected” 错误，说明 SSH 服务端拒绝了密码认证请求，核心原因集中在 SSH 服务端配置或账号本身的限制上。具体排查方向如下：

1. SSH 服务端禁用了密码认证

这是最常见的原因。尽管你想使用密码登录，但服务端可能默认关闭了密码认证功能。

• 检查配置：登录目标主机，查看 /etc/ssh/sshd_config 文件中是否有以下配置：

  PasswordAuthentication no  # 禁用密码认证
  ChallengeResponseAuthentication no  # 禁用挑战响应认证（部分系统会影响密码登录）
  

• 解决方法：

  1. 将 PasswordAuthentication 改为 yes（若被注释则取消注释）。
  2. 保存后重启 SSH 服务：

     # Ubuntu/Debian
     sudo systemctl restart ssh
     # CentOS/RHEL
     sudo systemctl restart sshd
     

2. 账号密码本身错误或账号被锁定

• 密码错误：即使你认为密码正确，也可能因大小写、特殊字符输入错误导致失败。建议在目标主机本地登录一次，确认密码正确性（本地登录成功但远程失败，说明是服务端配置问题）。
• 账号被锁定：若多次输错密码，系统可能通过 pam_tally2 或 faillock 锁定账号。
  • 解锁命令（需 root 权限）：

    # 查看锁定状态
    faillock --user 你的用户名
    # 解锁
    faillock --user 你的用户名 --reset
    

3. SSH 服务端限制了登录来源或用户

服务端可能通过配置限制了允许登录的用户或 IP，导致密码验证被直接拒绝。

• 检查 sshd_config 中的访问控制：

  # 查看是否有以下限制（若存在，需确保你的用户名在允许列表中）
  AllowUsers 特定用户名@IP  # 仅允许指定用户从指定IP登录
  DenyUsers 你的用户名      # 禁止你的用户登录
  

  若有以上配置，需删除或修改为允许你的用户登录。

4. PAM 认证模块阻止了登录

Linux 系统通过 PAM（Pluggable Authentication Modules）控制认证流程，若 PAM 配置异常，会直接拒绝密码验证。

• 检查 PAM 配置：查看 /etc/pam.d/sshd 文件，是否有类似以下限制：

  # 若存在此类行，可能限制了密码登录（注释或删除即可）
  auth       required     pam_deny.so
  

  注意：修改 PAM 配置需谨慎，错误配置可能导致所有登录失败。

5. 目标主机防火墙或安全软件拦截

部分防火墙或安全软件（如 SELinux、AppArmor）可能在认证阶段拦截请求，表现为 “Authentication Rejected”。

• 临时关闭 SELinux 测试（CentOS/RHEL 系统）：

  sudo setenforce 0  # 临时关闭（重启后恢复）
  

• 检查防火墙是否允许 SSH 端口：

  # 查看 SSH 端口（默认22）是否开放
  sudo ufw status  # Ubuntu/Debian
  sudo firewall-cmd --list-ports  # CentOS/RHEL
  

6. SSH 客户端与服务端版本兼容性问题

极少数情况下，客户端（Tabby）与服务端的 SSH 协议版本不兼容（如服务端仅支持 SSHv1，而客户端默认使用 SSHv2）。

• 强制客户端使用特定版本：在 Tabby 的连接配置中，尝试指定 SSH 版本（如添加 -1 或 -2 参数），或在服务端 sshd_config 中开启兼容配置：

  Protocol 2  # 确保支持 SSHv2（现代系统默认）
  

排查技巧

若以上方法仍无法解决，可通过查看服务端日志定位具体原因：

# Ubuntu/Debian 查看 SSH 日志
sudo grep sshd /var/log/auth.log

# CentOS/RHEL 查看 SSH 日志
sudo grep sshd /var/log/secure

日志中会明确记录拒绝原因（如 “Failed password”、“Permission denied” 等），根据提示进一步排查即可。

核心结论：密码验证被拒绝的本质是服务端不接受该密码或不允许密码登录，需从服务端配置、账号状态、认证权限三个维度逐步排查。

从你提供的 sshd_config 配置文件来看，大部分关键设置都是正常的，但有几个细节可能导致连接失败，结合配置内容分析如下：

1. 核心配置检查（已正常的部分）

• PasswordAuthentication yes：已正确开启了密码认证，这是密码登录的基础。
• PubkeyAuthentication yes：公钥认证也已启用（不影响密码登录）。
• UsePAM yes：启用了 PAM 认证模块（正常配置，通常不影响）。
• 没有明显的 AllowUsers/DenyUsers 限制（默认允许所有用户登录）。

2. 可能导致连接失败的潜在原因

（1）PermitRootLogin 配置隐含 默认限制 root 登录

配置中 PermitRootLogin prohibit-password 是注释状态（被 # 注释），但 OpenSSH 的默认行为是：

• 当该选项被注释时，默认值为 prohibit-password（即禁止 root 用户使用密码登录，仅允许密钥登录）。

如果你的登录用户是 root，即使 PasswordAuthentication yes，也会被拒绝密码登录。

• 解决：若需允许 root 密码登录，取消注释并修改为：

  PermitRootLogin yes
  

（2）MaxAuthTries 可能触发次数限制

配置中 MaxAuthTries 6 是注释状态，默认值为 6 次。但如果之前多次输错密码，可能已触发临时锁定（由 PAM 或系统安全策略控制）。

• 检查账号是否被锁定：

  # 查看失败次数（适用于多数系统）
  sudo faillock --user 你的用户名
  
  # 若被锁定，执行解锁
  sudo faillock --user 你的用户名 --reset
  

（3）PAM 配置可能拦截认证（与 UsePAM yes 相关）

虽然 sshd_config 中启用了 PAM（UsePAM yes），但 PAM 自身的配置文件（/etc/pam.d/sshd）可能存在限制。

• 检查 PAM 配置是否有异常：

  sudo cat /etc/pam.d/sshd
  

  若其中包含 auth required pam_deny.so 或类似拒绝认证的行，注释或删除即可。

（4）SSH 服务未加载最新配置

如果之前修改过 sshd_config 但未重启服务，配置可能未生效。

• 重启 SSH 服务：

  # 对于 systemd 系统（如 Ubuntu 16.04+、CentOS 7+）
  sudo systemctl restart sshd
  
  # 对于较旧的 sysvinit 系统
  sudo service sshd restart
  

（5）客户端连接命令或参数错误

即使服务端配置正确，客户端连接时的参数错误也会导致失败：

• 确保连接命令格式正确：

  ssh 用户名@目标主机IP -p 端口号  # 端口号默认22，若未修改可省略
  

• 若通过 Tabby 连接，检查配置中的「用户名」「主机地址」「端口」是否正确（尤其注意是否误填为密钥文件路径等）。

3. 通过日志定位具体原因

最直接的方式是查看 SSH 服务端日志，获取拒绝连接的详细信息：

# Ubuntu/Debian 系统
sudo grep sshd /var/log/auth.log

# CentOS/RHEL 系统
sudo grep sshd /var/log/secure

日志中会包含类似以下的关键信息，可精准定位问题：

• Failed password for 用户名 from IP port ...：密码错误
• Permission denied, please try again.：权限或配置限制
• Too many authentication failures：超过最大尝试次数

总结排查步骤

1. 若登录用户是 root，修改 PermitRootLogin yes 并重启服务。
2. 解锁可能被锁定的账号（faillock --reset）。
3. 检查 PAM 配置（/etc/pam.d/sshd）是否有拒绝规则。
4. 确认客户端连接参数（用户名、IP、端口）正确。
5. 查看服务端日志，根据具体错误信息进一步处理。