我来帮你捋捋这个问题——这种情况我在运维中碰到过好多次，大概率是权限、配置或者命令执行环节出了小疏漏，咱们一步步排查：

1. 权限配置错误（最常见原因） #

SSH对.ssh目录和authorized_keys的权限要求特别严格，只要权限太宽松，直接就会拒绝密钥登录。

• 先登录服务器，检查.ssh目录权限：

  ls -ld ~/.ssh
  

  正常权限应该是drwx------（也就是数值700，只有所有者能读写执行）。
• 再检查authorized_keys文件权限：

  ls -l ~/.ssh/authorized_keys
  

  正常权限是-rw-------（数值600，只有所有者能读写）。
• 如果权限不对，执行命令修正：

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

2. 管道命令执行时的隐藏问题 #

你用的cat | ssh管道命令如果遇到远程服务器上.ssh目录不存在的情况，不会弹出明显报错，但公钥根本没写入成功。

• 先登录服务器确认.ssh目录是否存在：ls -d ~/.ssh，如果不存在，手动创建并设置权限：

  mkdir ~/.ssh && chmod 700 ~/.ssh
  

• 或者换一种更稳妥的上传方式，用scp先传公钥到临时文件：

  scp ~/.ssh/id_rsa.pub root@xxx.xxx.xxx.xx:~/.ssh/temp_key.pub
  

  登录服务器后再追加到授权文件：

  cat ~/.ssh/temp_key.pub >> ~/.ssh/authorized_keys
  rm ~/.ssh/temp_key.pub
  

3. SSH服务配置限制 #

可能服务器的SSH配置文件禁用了密钥登录，或者指定了非默认的授权文件路径。

• 打开SSH配置文件/etc/ssh/sshd_config，检查以下两项：
  • PubkeyAuthentication 必须设置为 yes
  • AuthorizedKeysFile 应该是 ~/.ssh/authorized_keys（默认值，但可能被修改）
• 修改后记得重启SSH服务生效：

  systemctl restart sshd
  

4. 安全模块拦截（SELinux/AppArmor） #

如果服务器开启了SELinux或AppArmor，安全策略可能会阻止SSH读取authorized_keys文件。

• 临时关闭SELinux测试：setenforce 0，然后尝试密钥登录，如果成功，再修改配置文件永久调整（编辑/etc/selinux/config，将SELINUX=enforcing改为SELINUX=permissive）。
• 对于AppArmor，可以用aa-status查看SSH的profile状态，若有拦截，需要调整对应规则。

5. 公钥本身存在问题 #

可能你本地的id_rsa.pub是空的，或者传输过程中内容被截断。

• 先在本地检查公钥内容：cat ~/.ssh/id_rsa.pub，确保是一整行完整的字符串（开头是ssh-rsa/ecdsa-sha2-*等前缀，结尾是你的用户名@主机名）。
• 如果本地没生成过公钥，重新生成：ssh-keygen -t rsa（一路回车即可，不用设置密码）。

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