诊断和解决SSH身份验证失败

安全外壳（SSH）是安全远程管理的基石，能够加密访问服务器和网络设备。然而，遇到身份验证失败是系统管理员和开发人员常见且令人沮丧的经历。这些问题可能源于多种原因，从简单的拼写错误到复杂的权限问题或配置错误。

本文作为有效诊断和解决SSH身份验证失败的全面指南。我们将深入探讨系统化的故障排除方法，强调客户端详细输出和服务器端日志分析的关键作用。通过理解如何解读这些诊断线索，您将能够准确定位大多数身份验证问题的根本原因，并恢复安全的远程访问。

理解SSH身份验证方法

在深入故障排除之前，了解SSH使用的主要身份验证方法至关重要：

• 密码身份验证：用户提供密码，服务器根据其用户数据库或外部身份验证服务（如PAM）进行验证。
• 公钥身份验证：这种更安全的方法使用一对加密密钥：存储在客户端的私钥和存储在服务器上的相应公钥。在身份验证时，客户端使用其私钥证明身份，而无需通过网络发送私钥。

两种方法都可能发生身份验证失败，但故障排除步骤通常不同。

初始检查和常见陷阱

在深入详细日志之前，进行一些基本检查是明智的，因为许多问题往往是简单的疏忽：

• 正确的用户名和主机名：仔细检查您是否使用了正确的用户名和目标服务器的确切主机名或IP地址。
• 网络连接：您能否访问服务器？使用nc -vz host 22或ssh -vvv测试SSH可达性。ping可能有帮助，但许多服务器即使SSH正常工作也会阻止ICMP。

  ping example.com
  

• SSH服务状态：SSH服务器（sshd）是否在目标机器上实际运行？如果您有控制台访问权限，请检查其状态。

  sudo systemctl status sshd # 对于基于systemd的系统（大多数现代Linux）
  sudo service sshd status    # 对于较旧的init系统
  

• SSH端口：SSH守护进程是否在默认端口（22）或自定义端口上监听？如果是自定义端口，您需要使用-p指定。
• 防火墙规则：是否有任何防火墙（客户端或服务器端）阻止端口22（或您的自定义SSH端口）？检查服务器防火墙，如ufw、firewalld或AWS安全组。

  sudo ufw status
  sudo firewall-cmd --list-all
  

客户端诊断：利用详细模式

SSH客户端提供详细模式（-v、-vv、-vvv），提供关于连接过程和身份验证尝试的详细调试输出。这些输出对于理解客户端认为身份验证失败的原因非常宝贵。

使用详细标志

• -v：详细输出。
• -vv：更详细的输出。
• -vvv：最详细的输出（通常对身份验证问题最有用）。

示例命令：

ssh -vvv username@your_server_ip

解读详细输出

当您在详细模式下运行ssh时，查找指示身份验证过程失败位置的关键行：

• debug1: Authentications that can continue:：此行告诉您服务器愿意接受哪些身份验证方法。如果您期望的方法（例如publickey）未列出，则服务器配置阻止了它。

  debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
  

• debug1: Offering public key:：这表明您的客户端正在尝试使用特定的公钥进行身份验证。如果您期望公钥身份验证但没有看到此行，则您的客户端未找到或未提供该密钥。

  debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
  

• debug3: send_pubkey_test: ... trying private key: /home/user/.ssh/id_rsa：这确认客户端正在尝试使用特定的私钥。
• debug1: Server accepts key: ...：这表示从客户端的角度来看，公钥身份验证成功。如果您没有看到此行，则密钥可能被服务器拒绝。
• debug1: No more authentication methods to try.：这通常出现在Permission denied错误之前，意味着客户端已用尽所有可用的身份验证方法但未成功。
• debug1: Permission denied (publickey,password).：这是最终的客户端错误，总结了服务器对所有尝试的拒绝。

提示： 密切注意提供和接受的身份验证方法的顺序。如果提供了publickey但随后立即出现密码提示，通常意味着服务器拒绝了公钥。

服务器端诊断：检查SSH服务器日志

虽然客户端详细输出显示了客户端尝试做什么，但服务器日志提供了关于服务器为何拒绝身份验证尝试的确定性信息。这通常是根本原因分析中最关键的步骤。

定位SSH服务器日志

SSH服务器日志的位置因操作系统而异：

• Debian/Ubuntu及其衍生版：/var/log/auth.log
• RHEL/CentOS/Fedora及其衍生版：/var/log/secure
• 基于systemd的系统（大多数现代Linux）：您也可以使用journalctl。

查看和过滤服务器日志

使用tail或journalctl等工具实时监控日志或过滤SSH特定条目。

示例命令：

# 对于Debian/Ubuntu
sudo tail -f /var/log/auth.log | grep sshd

# 对于RHEL/CentOS
sudo tail -f /var/log/secure | grep sshd

# 对于基于systemd的系统（查看当前日志最可靠的方式）
sudo journalctl -u sshd -f

# 从头查看所有sshd日志（如果失败发生在更早的时间）
sudo journalctl -u sshd

常见服务器日志条目及其含义

在您尝试连接时查找与sshd相关的消息。以下是一些指示身份验证失败的常见条目：

• Failed password for user from IP port ssh2：表示密码身份验证尝试失败。这可能是由于密码错误，或者用户不允许通过密码登录。
• Authentication refused: bad ownership or modes for directory /home/user/.ssh：这是一个非常常见的公钥身份验证错误。服务器上的.ssh目录权限不正确。
  • 解决方案：chmod 700 /home/user/.ssh
• Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys：另一个常见的公钥错误，表示authorized_keys文件权限不正确。
  • 解决方案：chmod 600 /home/user/.ssh/authorized_keys
• sshd[PID]: error: Permissions 0777 for '/home/user/.ssh/authorized_keys' are too open.：明确指出了文件权限过于宽松的问题。出于安全原因，SSH对权限非常严格。
• User username from IP not allowed because not listed in AllowUsers：根据/etc/ssh/sshd_config中的AllowUsers指令，该用户不允许通过SSH登录。
• User username from IP not allowed because listed in DenyUsers：该用户被DenyUsers明确拒绝SSH访问。
• input_userauth_request: invalid user username：提供的用户名在服务器上不存在。
• Failed publickey for user 或重复提供的密钥后跟密码：客户端提供的公钥与该用户接受的密钥不匹配，或者服务器因权限或策略拒绝该密钥。
• Maximum authentication attempts exceeded for user from IP：客户端尝试了太多身份验证方法或发送了太多错误凭据。由sshd_config中的MaxAuthTries控制。
• Connection closed by authenticating user IP port 22 [preauth]：如果未找到可接受的身份验证方法，或者客户端在失败后突然关闭连接，可能会发生这种情况。

常见身份验证失败场景及解决方案

让我们对常见失败进行分类并提供具体解决方法。

1. 密码身份验证失败

• 密码错误：最直接的问题。仔细检查您的密码。注意键盘布局、大写锁定或数字锁定。
• 用户不被允许：sshd_config文件（/etc/ssh/sshd_config）可能限制某些用户的登录。
  • PermitRootLogin no：阻止root登录（出于安全原因强烈推荐）。
  • AllowUsers username1 username2：只有指定用户可以登录。
  • DenyUsers username：指定用户不能登录。
  • AllowGroups groupname：只有指定组中的用户可以登录。
  • 解决方案：调整sshd_config指令并重启sshd。
• PAM问题：如果服务器使用可插拔身份验证模块（PAM），PAM配置问题可能会阻止密码身份验证。检查/var/log/auth.log中的PAM特定错误。对于基本SSH设置，这不太常见。

2. 公钥身份验证失败

公钥身份验证通常更安全，但更容易出现与配置相关的错误。

• 文件/目录权限不正确（服务器端）：这是迄今为止最常见的原因。出于安全原因，SSH要求~/.ssh和~/.ssh/authorized_keys具有严格的权限。
  • ~：用户的主目录不应是全局可写的（chmod 755 ~通常是安全的）。
  • ~/.ssh：必须为700（仅所有者可读写执行）。

    chmod 700 ~/.ssh
    

  • ~/.ssh/authorized_keys：必须为600（仅所有者可读写）。

    chmod 600 ~/.ssh/authorized_keys
    

  • 这些文件和目录的所有者必须是尝试登录的用户。

    sudo chown -R username:username ~/.ssh
    

• authorized_keys内容不正确：~/.ssh/authorized_keys中的公钥可能已损坏、包含多余字符或格式不正确。每个密钥应单独占一行。确保正确格式的快速方法是从客户端使用ssh-copy-id。

  ssh-copy-id -i ~/.ssh/id_rsa.pub username@your_server_ip
  

  要验证客户端上的公钥指纹，请使用： ssh-keygen -l -f ~/.ssh/id_rsa.pub
• 客户端未提供密钥：私钥可能不在默认位置（~/.ssh/id_rsa）、未加载到ssh-agent中，或者您未使用-i指定。
  • 解决方案：确保您的私钥是id_rsa（或id_ed25519等）位于~/.ssh中，并且权限为600。如果不是，请指定：

    ssh -i /path/to/your/private_key username@your_server_ip
    

  • 如果使用ssh-agent，请确保添加了您的密钥：

    eval "$(ssh-agent -s)"
    ssh-add ~/.ssh/your_private_key
    

• sshd_config禁止公钥身份验证：服务器的SSH守护进程可能配置为禁止公钥身份验证。
  • 检查/etc/ssh/sshd_config中的PubkeyAuthentication yes。
  • 检查AuthorizedKeysFile .ssh/authorized_keys以确保它指向正确的文件。默认值通常没问题。
  • 解决方案：设置PubkeyAuthentication yes并重启sshd。
• SELinux/AppArmor干扰：在具有SELinux或AppArmor的系统上，这些安全模块有时会阻止SSH访问用户主目录或.ssh文件，即使文件权限正确。检查审计日志（/var/log/audit/audit.log或sudo ausearch -m AVC -ts recent）以获取线索。这是一个高级场景。

3. 连接被拒绝或超时

虽然严格来说不是“身份验证”失败，但这些通常发生在身份验证尝试之前，并阻止它们开始。

• 防火墙阻止：检查客户端（例如本地操作系统防火墙）和服务器（例如ufw、firewalld、云安全组、网络ACL）上的防火墙。确保端口22（或自定义端口）已打开。
• SSH服务器未运行：sshd服务可能未激活或已崩溃。
• 端口/IP错误：尝试连接到错误的端口或IP地址。

一般调试技巧

• 检查sshd_config：始终检查服务器上的/etc/ssh/sshd_config，查找可能干扰的非默认设置。更改后，始终重启SSH守护进程：sudo systemctl restart sshd（或sudo service sshd restart）。
• 使用新用户/密钥测试：如果可能，创建一个新用户和一个新的公钥/私钥对。尝试使用这个全新设置进行身份验证。如果有效，则问题特定于原始用户的配置。
• 隔离问题：尝试从不同的客户端机器连接。如果有效，则问题是客户端特定的。如果从多个客户端失败，则问题是服务器特定的。
• 增加日志级别（服务器端）：对于深度调试，您可以临时在/etc/ssh/sshd_config中设置LogLevel DEBUG并重启sshd。故障排除后记得恢复此设置，因为调试日志可能非常详细并消耗磁盘空间。

要点

使用ssh -vvv查看客户端提供的内容，然后检查服务器日志以了解sshd拒绝的原因。大多数公钥失败归结为密钥错误、authorized_keys条目缺失、严格的文件权限或阻止用户或方法的sshd_config规则。