开机自动分发SSH公钥不安全且不可靠，因其违背一次性配置原则、依赖未就绪网络、需明文密码或免密通道；应改用部署阶段批量分发、systemd oneshot服务或镜像预置方案。
开机自动分发 SSH 公钥本身不是一个标准或推荐的系统启动行为。SSH 公钥是用户级认证凭证，应由管理员在部署阶段主动、可控地分发，而不是让系统在每次开机时“自动重推”——这既不安全，也不符合 SSH 的设计逻辑（公钥只需写入一次，长期有效）。
为什么不能也不该“开机自动分发”公钥
• 公钥分发本质是**一次性配置操作**，不是运行时服务。重复执行可能覆盖、追加冗余条目，甚至因权限错误导致免密失效。
• 开机阶段网络未必就绪（如 DHCP 延迟、网卡未 up），ssh 连接极大概率失败。
• 自动执行 ssh-copy-id 或管道命令需明文密码或已存在的免密通道，违背最小权限和安全原则。
• 若目标主机已禁用密码登录（PasswordAuthentication no），开机脚本将彻底卡死或静默失败，难以排查。
真正可行且安全的替代方案
• 首次部署时用脚本批量完成：在服务器初始化阶段（如 cloud-init、Ansible playbook、Packer 构建镜像时），用带超时和错误检查的 Bash 脚本一次性分发公钥，而非依赖开机触发。
• 用 systemd 服务做“首次启动后仅运行一次”的配置：可编写一个 `oneshot` 类型的 systemd unit，在系统首次启动后检查 `.ssh/authorized_keys` 是否存在且内容正确，若缺失则执行分发（仍需确保网络就绪、凭据可用）。
• 把公钥预置进系统镜像或用户家目录模板：例如在创建新用户时，将 `authorized_keys` 文件随 skeleton 目录一起复制，并设好权限（700/600），一劳永逸。
如果坚持要在启动流程中集成（仅限受控环境）
需满足三个前提：
• 目标主机已开启密码登录（临时）、网络已就绪、sshd 正在运行；
• 本地私钥无密码（或配合 keychain），且 `~/.ssh/id_rsa.pub` 已存在；
• 使用 `systemd-run --on-active=30s` 或 `@reboot` cron（不推荐）延迟执行，避开启动争抢。
示例（仅作技术说明，勿直接用于生产）：
cat /etc/systemd/system/ssh-key-deploy.service[Unit]
Description=Deploy SSH public key on first boot
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'if [ ! -f /root/.ssh/authorized_keys ]; then mkdir -p /root/.ssh && chmod 700 /root/.ssh && cat /root/.ssh/id_rsa.pub | tee /root/.ssh/authorized_keys && chmod 600 /root/.ssh/authorized_keys; fi'
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
然后启用：
systemctl daemon-reload && systemctl enable ssh-key-deploy.service
更务实的做法：免密登录 + 开机自启 SSH 服务
你真正需要的，其实是：
✓ 确保 sshd 开机自启（systemctl enable sshd）
✓ 在部署阶段就完成公钥分发（用 ssh-copy-id 或管道命令）
✓ 验证 PubkeyAuthentication yes 和 PasswordAuthentication no 已正确配置并重启 sshd
✓ 所有权限（~/.ssh 700，authorized_keys 600）一步到位
这样系统每次开机，SSH 服务就绪，且免密登录立即可用——无需“再分发”。
