解决常见的 SSH 'Permission Denied' 错误和连接问题

安全外壳 (SSH) 是远程服务器管理的基础，它提供了加密通信来访问和控制远程系统。尽管 SSH 非常可靠，但设置过程，尤其是基于密钥的身份验证，有时会导致令人沮丧的连接失败。最常见的罪魁祸首就是可怕的 Permission denied（权限拒绝）错误。

这份全面的指南将引导您诊断和解决最常见的 SSH 错误。我们将特别关注理解 Permission denied (publickey) 背后的根本原因，并解决与文件权限、配置不正确以及客户端/服务器设置不匹配相关的常见陷阱。掌握这些故障排除步骤，可确保您的远程基础设施访问安全可靠。

理解 SSH 身份验证流程

在进行故障排除之前，了解 SSH 如何验证用户身份至关重要。当您尝试连接时，服务器通常按以下顺序检查凭证（取决于配置）：

公钥身份验证 (Public Key Authentication)： 客户端提供一个公钥，服务器检查相应的私钥是否有效，并与一个授权密钥 (authorized_keys 文件) 匹配。
密码身份验证 (Password Authentication)： 如果密钥身份验证失败或被禁用，服务器会提示输入密码。

当您收到 Permission denied 时，几乎总是意味着服务器在步骤 1 或步骤 2 拒绝了您的凭证。

诊断连接问题：详细模式 (Verbose Mode) 的力量

诊断 SSH 问题的最有效工具是使用详细模式运行客户端。通过添加 -v、-vv 或 -vvv 标志，客户端会输出有关协商过程的详细调试信息。

使用详细标志

使用以下命令结构：

ssh -vvv user@remote_host

在输出中查找什么：

密钥交换： 查找指示客户端尝试了哪些身份验证方法的行（例如，Offering RSA key: /path/to/id_rsa）。
服务器响应： 密切关注服务器的拒绝消息。如果输出显示服务器正在检查密钥但无法匹配，则问题可能在于服务器端的密钥配置或权限。
密码提示： 如果输出跳过了密钥检查并立即要求输入密码，则服务器上可能禁用了密钥身份验证。

解决 `Permission denied (publickey)`

此错误明确指出服务器拒绝了所提供的公钥凭证。解决方案通常在于权限或密钥配对。

1. 检查密钥文件权限（客户端）

出于安全原因，SSH 客户端对您的私钥文件（例如，~/.ssh/id_rsa）的权限要求非常严格。如果这些文件的权限过于开放，客户端将拒绝使用它们。

可操作的修复（客户端）： 确保您的私钥仅对您自己可读。

chmod 600 ~/.ssh/id_rsa

2. 验证密钥是否存在并正确使用

确保您使用正确的身份文件连接，尤其当您使用非标准密钥或多个密钥对时。

可操作的修复（客户端）： 使用 -i 标志指定正确的私钥。

ssh -i /path/to/your/specific_private_key user@remote_host

3. 服务器端权限和所有权

这是最常见的失败原因。SSH 对您尝试登录的用户在服务器上的目录和文件权限实施严格的限制。

服务器上的路径	所需权限	所有者
`~/.ssh` 目录	`700` (rwx------)	用户
`~/.ssh/authorized_keys` 文件	`600` (rw-------)	用户

可操作的修复（服务器）： 通过控制台或密码身份验证（如果启用）登录并运行这些命令：

# 设置目录权限
chmod 700 ~/.ssh

# 设置 authorized_keys 权限
chmod 600 ~/.ssh/authorized_keys

# 验证所有权（将 'myuser' 替换为实际用户名）
chown -R myuser:myuser ~/.ssh

警告： 如果用户主目录 (~/) 上的权限过于宽松（例如，可被组或其他用户写入），出于安全原因，SSH 也可能会失败。如果问题持续存在，请确保 ~/ 的权限为 755 或更严格。

4. 确认密钥已实际添加

确保客户端上的公钥字符串与粘贴到服务器 ~/.ssh/authorized_keys 文件中的内容完全匹配。缺少字符或尾随空格都将导致身份验证失败。

提示： 添加密钥时，如果可用，请使用 ssh-copy-id，因为它会自动处理权限和格式：

ssh-copy-id user@remote_host

解决配置文件问题 (`sshd_config`)

如果密钥和权限都正确，问题通常出在 SSH 守护进程配置文件中，该文件通常位于服务器的 /etc/ssh/sshd_config。

1. 检查身份验证方法

确保公钥身份验证被明确允许。

配置检查： 查找以下行并确保它们已取消注释 (#) 并设置正确：

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

2. 密码身份验证状态

如果您暂时依赖密码登录，请验证它是否已启用。如果设置为 no，您必须使用密钥。

PasswordAuthentication yes

3. PermitRootLogin

如果您尝试以 root 身份登录，请确保允许此操作。最佳实践通常是以标准用户身份登录并使用 sudo，但为了进行故障排除，您可以检查此设置：

PermitRootLogin yes

关键步骤： 对 /etc/ssh/sshd_config 进行任何更改后，您必须重新启动 SSH 服务才能使更改生效：
bash sudo systemctl restart sshd # 或 service ssh restart

其他常见的连接错误

虽然密钥问题是主要的，但其他错误也可能阻止访问：

A. Connection Timed Out（连接超时）

这通常意味着客户端根本无法联系到服务器，表明是网络问题，而非身份验证问题。

可能原因：
* 服务器已关闭或无法访问。
* 防火墙（本地或网络）正在阻止端口 22（或自定义 SSH 端口）上的连接。
* IP 地址或主机名不正确。

故障排除： 使用 ping 检查基本连通性，并使用 telnet 或 nc (netcat) 检查端口是否打开：

# 检查端口 22 是否可达
telnet remote_host 22

B. No Route to Host（无到主机的路由）

与连接超时类似，这是一个网络基础设施问题。客户端找不到到达服务器 IP 地址的路径。请检查路由表、VPN 状态，或确保远程服务器具有有效的网络接口处于活动状态。

C. Server Refused Our Key（服务器拒绝了我们的密钥）

如果详细输出显示服务器正在主动拒绝密钥，但您已验证了 authorized_keys 文件，请检查服务器上的 SELinux 或 AppArmor 安全上下文。如果上下文不正确，这些安全模块可能会覆盖文件权限并阻止 SSH 访问。

最佳实践总结

诊断时始终使用详细模式 (-vvv)。
客户端密钥安全： 确保私钥设置为 600 (chmod 600)。
服务器文件完整性： 验证 ~/.ssh 为 700 且 authorized_keys 为 600。
重新启动守护进程： 修改 /etc/ssh/sshd_config 后，始终重新启动 sshd。
尽可能使用 ssh-copy-id 来自动化密钥部署。