最稳妥推荐直接运行：ssh-keygen -t ed25519 -C "your_email@example.com"；ED25519比RSA更快更安全，是OpenSSH默认首选，不加-f保持默认路径，私钥权限必须为600，目标端authorized_keys目录权限须为700、文件权限600，且sshd_config中PubkeyAuthentication需设为yes。
直接用 ssh-keygen 就行，别改默认路径、别跳过权限检查，否则后续连不上不是密钥问题，而是 OpenSSH 拒绝读取。
用什么命令生成最稳妥
推荐直接运行：ssh-keygen -t ed25519 -C "your_email@example.com"。ED25519 比 RSA 更快更安全，且是当前 OpenSSH 默认首选；-C 后的注释只是方便识别，不填也行，会自动用 $USER@$HOSTNAME 替代。
如果目标环境较老（比如 CentOS 7 或某些嵌入式设备），才退而求其次用：ssh-keygen -t rsa -b 4096 -C "your_email@example.com"。RSA 2048 已被部分审计工具标为弱密钥，4096 是底线。
不要加 -f 手动指定路径（比如 -f /tmp/mykey），否则 ssh 客户端默认找不到它，每次连接都得显式带 -i /tmp/mykey，极易漏掉。
生成时权限和路径必须对齐用户身份
密钥最终落在哪，取决于你以谁的身份执行 ssh-keygen：
- 普通用户执行 → 密钥存进
~/.ssh/id_ed25519和~/.ssh/id_ed25519.pub - root 用户执行 → 落在
/root/.ssh/下 - 目标登录用户是
www→ 必须先sudo -u www -i切过去再运行，不能在 root 下生成完拷过去
原因：OpenSSH 服务端校验时，会严格比对 authorized_keys 所在目录的属主与登录用户名是否一致。属主不对，直接拒绝认证，连日志都不报错。
为什么 ssh-copy-id 有时静默失败
它只负责“把公钥追加进 authorized_keys”，但前提是目标端 ~/.ssh 目录存在且权限是 700，authorized_keys 文件权限是 600，且用户主目录（如 /home/deploy）权限不能是 777。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
常见静默失败场景：
- 目标服务器是全新系统，
~/.ssh目录根本不存在 - 一键脚本重置了
/home/xxx权限为777，OpenSSH 会直接跳过读取密钥 -
authorized_keys被覆盖写成了644，服务端拒绝加载
手动补救（在目标服务器上运行）：
chmod 700 ~/.ssh touch ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys cat /path/to/id_ed25519.pub >> ~/.ssh/authorized_keys
服务端配置不启用，本地密钥再标准也没用
生成和分发完公钥后，必须确认目标服务器的 /etc/ssh/sshd_config 包含以下三项且未被注释：
-
PubkeyAuthentication yes（必须，否则压根不走密钥流程） -
AuthorizedKeysFile .ssh/authorized_keys（确认路径没被改成.ssh/authorized_keys2等） -
PasswordAuthentication no（可选，但禁用密码前务必先用新密钥成功登一次）
改完必须重启服务：sudo systemctl restart sshd。systemd 不会自动 reload 配置，reload 常常不生效。
最容易被忽略的是：私钥文件（id_ed25519）本身权限必须是 600，哪怕只多一个 group 可读位，OpenSSH 客户端也会拒绝加载——它连提示都懒得打，直接 fallback 到密码。
