这种情况确实挺让人困惑的——明明密钥内容完全一致，root账号能正常验证，换到普通用户就不行。结合你给出的细节（权限设置正确、ssh -v显示服务器拒绝密钥），我帮你梳理几个最可能的排查方向，按优先级来：

1. 优先检查SELinux上下文（Fedora默认启用，大概率是这个问题） #

Fedora默认开启SELinux，它会对文件的安全上下文做严格限制。你手动把root的authorized_keys内容复制到普通用户目录后，很可能文件的SELinux标签还保留着root的上下文，导致sshd拒绝读取。

• 先查看当前authorized_keys的SELinux标签：

  ls -Z /home/kevin/.ssh/authorized_keys
  

  正常情况下，普通用户的这个文件标签应该是类似unconfined_u:object_r:ssh_home_t:s0的格式。如果显示的是system_u:object_r:admin_home_t:s0（root目录的标签），那就是问题所在。

• 修复上下文：

  restorecon -Rv /home/kevin/.ssh
  

  这个命令会自动把.ssh目录下的文件恢复到正确的SELinux上下文，之后再尝试连接应该就能正常验证了。

2. 检查用户家目录的权限 #

虽然你已经确认了.ssh目录（700）和authorized_keys（600）的权限，但如果用户的家目录/home/kevin权限太宽松（比如777），sshd会因为安全原因拒绝使用密钥登录。

• 查看家目录权限：

  ls -ld /home/kevin
  

  权限应该设置为755（所有者读/写/执行，组和其他读/执行）或者更严格的700，如果是777的话，用以下命令修改：

  chmod 755 /home/kevin
  

3. 检查sshd_config的用户限制配置 #

登录失败也可能是sshd的全局配置限制了普通用户：

• 打开Callee的/etc/ssh/sshd_config，检查以下配置项：
  • AllowUsers：如果存在这个配置，必须包含kevin，否则会被拒绝登录；如果没有这个配置则跳过。
  • DenyUsers：确认里面没有列出kevin。
  • PubkeyAuthentication：确保这个值是yes（默认是开启的，但如果被注释或设为no会导致密钥登录失败）。

修改配置后记得重启sshd服务：

systemctl restart sshd

4. 开启sshd详细日志排查 #

如果以上步骤都没解决问题，可以临时调高sshd的日志级别，获取更详细的失败原因：

• 修改/etc/ssh/sshd_config中的LogLevel为DEBUG3：

  sed -i 's/^LogLevel.*/LogLevel DEBUG3/' /etc/ssh/sshd_config
  

• 重启sshd服务，然后再次尝试从Caller连接Callee的kevin用户。
• 查看Callee的日志文件（Fedora通常是/var/log/secure或你提到的/var/log/security），里面会明确说明拒绝登录的具体原因，比如密钥文件读取失败、SELinux拦截等。

5. 再次验证密钥指纹一致性 #

虽然你说authorized_keys内容一致，但还是可以用指纹再确认一遍，避免复制时出现字符遗漏或格式错误：

• 在Caller的root账号下，查看本地私钥的指纹：

  ssh-keygen -lf /root/.ssh/id_ed25519
  

• 在Callee的kevin账号下，查看authorized_keys中对应密钥的指纹：

  ssh-keygen -lf /home/kevin/.ssh/authorized_keys
  

  两个指纹必须完全一致，否则说明密钥内容确实有差异。

备注：内容来源于stack exchange，提问作者4Dummies