SSH密钥已配置，为何仍提示输入密码？

Question

尽管已配置SSH密钥，连接远程服务器时仍提示输入密码，常见原因是私钥权限过于开放。OpenSSH默认要求本地私钥文件（如 `~/.ssh/id_rsa`）的权限必须为 `600`，若权限过大（如 `644` 或更宽松），SSH客户端将跳过密钥认证并回退至密码登录。可通过执行 `chmod 600 ~/.ssh/id_rsa` 修复。此外，确保公钥已正确添加到目标服务器的 `~/.ssh/authorized_keys` 文件中，且该文件及目录权限设置恰当（`.ssh` 目录为 `700`，`authorized_keys` 为 `600`）。SELinux 或 AppArmor 等安全模块异常也可能导致此问题。

Answer 1

1. 问题现象与初步诊断

在使用SSH密钥进行远程服务器连接时，尽管已正确生成并部署了公私钥对，系统仍提示输入密码。这种行为通常表明密钥认证流程未能成功执行。最常见的原因是本地私钥文件权限设置不当。OpenSSH客户端出于安全考虑，默认要求私钥文件（如 ~/.ssh/id_rsa）的权限必须为 600（即仅所有者可读写）。若权限过于宽松（例如 644 或 755），SSH将自动跳过该密钥并回退至密码认证方式。

chmod 600 ~/.ssh/id_rsa
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

2. 权限配置标准与修复方法

SSH协议的安全模型依赖于严格的文件权限控制。以下是关键路径的标准权限设置：

文件/目录	推荐权限	说明
~/.ssh	700	仅用户自身可访问
~/.ssh/id_rsa	600	防止其他用户或进程读取私钥
~/.ssh/authorized_keys	600	避免被篡改或泄露
~/.ssh/config	600	配置文件也需保护

3. 公钥部署验证流程

即使本地私钥权限正确，若目标服务器未正确接收公钥，认证依然失败。应确保以下步骤完成：

1. 使用 ssh-keygen 生成密钥对
2. 通过 ssh-copy-id user@host 自动推送公钥
3. 手动检查 ~/.ssh/authorized_keys 是否包含完整公钥内容
4. 确认该文件无多余换行或截断
5. 检查远程用户主目录权限不应为全局可写（如 777）
6. 验证 /etc/ssh/sshd_config 中启用 PubkeyAuthentication yes
7. 重启sshd服务后测试连接

4. 安全模块干扰分析（SELinux/AppArmor）

现代Linux发行版常启用强制访问控制机制，可能阻止SSH正常读取密钥文件。例如，在CentOS/RHEL系统中，SELinux上下文错误会导致如下问题：

# 查看SELinux状态
sestatus

# 检查.ssh目录上下文
ls -Z ~/.ssh/

# 修复默认上下文
restorecon -R ~/.ssh

类似地，Ubuntu等系统使用AppArmor，可通过日志 /var/log/kern.log 搜索 apparmor 拒绝记录来定位问题。

5. 调试与日志追踪策略

启用详细输出是排查SSH连接问题的关键手段。使用 -v 参数逐级增加日志级别：

ssh -vvv user@remote_host

典型输出中会显示“Offering public key”、“Server refused our key”等线索，帮助判断是客户端跳过密钥、服务器拒绝还是权限问题。

6. 高级场景与自动化检测流程图

对于运维团队，建议建立标准化的SSH密钥健康检查流程：

graph TD A[开始SSH连接测试] --> B{是否提示密码?} B -- 是 --> C[检查本地私钥权限] C --> D[chmod 600 ~/.ssh/id_rsa] D --> E[验证authorized_keys存在且权限正确] E --> F[检查远程.ssh目录权限] F --> G[查看SELinux/AppArmor状态] G --> H[启用ssh -vvv调试] H --> I[分析拒绝原因] I --> J[修复并重试] J --> K[成功连接] B -- 否 --> K