SSH密钥登录失败八成因权限问题：私钥须chmod 600、.ssh目录须chmod 700、authorized_keys须600且属主正确；用ssh -v确认是否出现“Offering public key”以判断密钥是否被选用。
SSH 密钥登录失败，八成是权限惹的祸。OpenSSH 对文件和目录权限极其严格，稍有宽松就会静默跳过密钥，不报错、不提示，只返回 Permission denied (publickey)。
检查客户端私钥与 .ssh 目录权限
客户端 SSH 会拒绝加载权限过宽的私钥或目录，这是第一道硬性门槛：
- 私钥文件（如
~/.ssh/id_rsa或id_ed25519）必须为 600：仅所有者可读写 -
~/.ssh目录必须为 700：禁止组和其他用户访问 - 家目录（
~）不能被组或其他用户写入（即不能是775、777等）
快速修复命令：
chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_*.key 2>/dev/null验证服务端 authorized_keys 及其所在路径权限
服务端同样执行权限校验，任意一级不合规都会导致公钥被忽略：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
~/.ssh/authorized_keys文件权限必须为 600 -
~/.ssh目录权限必须为 700 - 用户主目录（
/home/username）不能被组或其他用户写入
常见误操作：用 sudo cp 或 sudo echo 写入 authorized_keys，导致文件属主变成 root，或权限失控。务必用普通用户身份操作，或修复后运行：
确认私钥是否被客户端实际选用
权限正确 ≠ 客户端用了这把密钥。默认情况下，SSH 只尝试有限几个固定名称（id_rsa、id_ecdsa、id_ed25519 等），不会自动扫描所有密钥：
- 显式指定私钥路径：
ssh -i ~/.ssh/my_key user@host - 用
ssh -v观察日志中是否出现Offering public key—— 若没有，说明客户端根本没选中你的密钥 - 检查
~/.ssh/config是否配置了错误的IdentityFile覆盖默认行为
排查 SELinux 或文件系统上下文干扰（仅限启用 SELinux 的系统）
在 CentOS/RHEL 等启用 SELinux 的环境中，即使权限全对，错误的安全上下文也会阻止 sshd 读取 authorized_keys：
- 临时禁用 SELinux 验证是否是根源：
sudo setenforce 0，再试登录 - 若恢复后仍失败，修复上下文：
sudo restorecon -Rv ~/.ssh - 查看当前上下文：
ls -Z ~/.ssh ~/.ssh/authorized_keys，正常应为unconfined_u:object_r:ssh_home_t:s0
