ssh-copy-id能直接推送公钥，但需目标ssh服务开启、pubkeyauthentication启用、本地存在有效密钥；它不生成密钥、不修复权限或selinux限制，失败主因是密钥缺失、权限错误或服务端配置未生效。
免密码登录本身不能靠“一个脚本”全自动搞定，核心是密钥分发 + 权限控制 + 服务端配置三者协同；任何号称“一键免密”的脚本，若跳过权限检查或忽略 StrictModes 验证，大概率会在连接时静默失败。
ssh-copy-id 失败时该检查什么
很多脚本卡在 ssh-copy-id 这一步，不是命令没运行，而是远程主机拒绝写入 authorized_keys。常见原因有：
-
/etc/ssh/sshd_config中PubkeyAuthentication被注释或设为no -
AuthorizedKeysFile指向了错误路径（比如改成了.ssh/authorized_keys2但脚本仍往默认路径写） - 远程用户主目录或
~/.ssh所在分区挂载时用了noexec或nosuid -
sshd进程未重载配置（改完sshd_config后漏掉sudo systemctl reload sshd）
手动部署公钥时权限必须严格
SSH 服务端默认启用 StrictModes yes，一旦发现 ~/.ssh 或 authorized_keys 权限过宽，会直接忽略该密钥——不报错、不提示，只退回密码登录。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
~/.ssh目录权限必须是700（drwx------），不能是755或777 -
~/.ssh/authorized_keys文件权限必须是600（-rw-------），不能是644 - 用户主目录（
~）不能是777，否则部分 OpenSSH 版本也会拒用密钥
脚本里别硬编码 id_rsa
用 ssh-keygen -t ed25519 生成的密钥默认叫 id_ed25519，而多数老脚本只认 id_rsa。如果脚本里写死 -i ~/.ssh/id_rsa.pub，但你实际用的是 ed25519 密钥，就会传错公钥。
- 生成密钥时明确指定文件名：
ssh-keygen -t ed25519 -f ~/.ssh/mykey - 后续所有操作（
ssh-copy-id、~/.ssh/config中的IdentityFile）都用这个自定义名 - 避免依赖默认名，也避免不同算法密钥混用导致的覆盖或误读
跨用户或 root 登录要额外注意路径
脚本若以普通用户身份运行，却想给 root 配置免密，ssh-copy-id root@host 默认会把公钥写进 /root/.ssh/authorized_keys，但前提是当前用户能 sudo 写该路径，且 /root 目录可被非 root 用户访问（通常不可）。
- 更稳妥的做法：先用普通用户登录，再
sudo su -进入 root 环境，手动执行mkdir -p /root/.ssh && chmod 700 /root/.ssh - 然后用
sudo sh -c "cat /home/xxx/.ssh/id_ed25519.pub >> /root/.ssh/authorized_keys" - 最后
sudo chmod 600 /root/.ssh/authorized_keys
绕过这些细节的脚本，往往只在“同用户同系统”场景下有效，一换环境就失效。
