使用密钥在两台服务器间执行SCP时出现Permission denied (publickey)错误求助

碰到这种情况确实挺头疼的——明明密钥是对的，却连不上还没日志线索，我来分享几个我常用的排查思路，大概率能帮你定位问题：

• 先手动测试SSH连接，排除SCP本身的问题
  别先盯着SCP，先直接用ssh -v user@remote-host命令连远程服务器，加上-v参数能输出详细的调试日志。哪怕你觉得密钥没问题，这个步骤能帮你看到密钥交换的全过程：比如本地有没有尝试用正确的私钥？远程端有没有接受这个公钥？有时候SCP的问题其实是底层SSH认证的问题，用verbose模式能揪出细节。

• 检查密钥文件的权限（重中之重！）
  这个是最容易踩的坑，SSH对密钥文件的权限要求特别严格：

  • 本地的私钥文件（比如~/.ssh/id_rsa）权限必须是600，也就是只有所有者能读写，用命令chmod 600 ~/.ssh/id_rsa修正。
  • 本地的.ssh目录权限得是700，执行chmod 700 ~/.ssh。
  • 远程服务器上的~/.ssh目录权限必须是700，authorized_keys文件权限必须是600，如果权限太松，SSH会直接拒绝用这个密钥认证，而且有时候不会在常规日志里留下记录。

• 确认远程服务器的SSH配置是否限制了密钥认证
  登录远程服务器，检查/etc/ssh/sshd_config文件里的几个关键配置：

  • PubkeyAuthentication必须设为yes
  • AuthorizedKeysFile的路径是否正确（默认是~/.ssh/authorized_keys，如果改了路径要确保公钥放在对应位置）
  • 有没有Match规则针对你的用户或者IP限制了认证方式？比如有些配置会给特定用户禁用密钥认证，这时候哪怕密钥对也没用。
    修改完配置记得重启sshd服务：sudo systemctl restart sshd（不同系统可能命令不同，比如CentOS是service sshd restart）

• 检查SELinux/AppArmor等安全模块的影响
  有时候这些安全模块会阻止SSH读取密钥文件或者完成认证操作，但不会在SSH日志里体现。可以临时关闭试试：

  • SELinux：执行sudo setenforce 0，然后再测试SCP，如果能连上了，说明是SELinux的问题，需要调整上下文或者添加规则。
  • AppArmor：执行sudo systemctl stop apparmor测试，之后再按需配置。

• 确认你用的是正确的用户和密钥
  别笑，有时候会犯低级错误：比如SCP命令里写的用户和你放公钥的用户不是同一个？或者本地指定了错误的私钥？试试用scp -i /path/to/your/private/key file user@remote-host:/target/path明确指定私钥文件，确保用的是正确的那对密钥。

内容的提问来源于stack exchange，提问作者edasac