1. 为什么 Ubuntu 上的 SSH 密钥不是“配个密钥就完事”——从一次凌晨三点的连接失败说起上周三凌晨我正远程调试一台部署在实验室机房的 Ubuntu 22.04 服务器突然 VS Code Remote-SSH 插件报错ssh: connect to host 192.168.10.5 port 22: Connection refused。我第一反应是服务挂了systemctl status ssh显示 active (running)再试ss -tlnp | grep :22端口明明监听着。接着换本地终端ssh user192.168.10.5这次报的是Permission denied (publickey)。我翻出自己半年前生成的id_rsa.pub确认已用ssh-copy-id推送过但就是连不上。最后发现/etc/ssh/sshd_config里PubkeyAuthentication yes被某次系统更新悄悄改成了no而AuthorizedKeysFile的路径也因 OpenSSH 版本升级从.ssh/authorized_keys变成了.ssh/authorized_keys %u%u 表示用户名导致密钥文件实际没被读取。这个坑让我熬到四点也彻底打消了我对“SSH 密钥配置运行两行命令”的幻想。这恰恰是绝大多数人踩坑的起点把ssh-keygen和ssh-copy-id当成魔法咒语却完全忽略它们背后依赖的三层信任链——客户端密钥对的生成与保护、服务端 SSH 守护进程的认证策略配置、以及操作系统级的文件权限与路径约束。Ubuntu 作为最主流的 Linux 发行版之一其默认 SSH 配置看似开箱即用实则在安全加固、多用户隔离、SELinux/AppArmor 策略、甚至 systemd 服务单元的启动顺序上都埋着大量隐性开关。比如你用sudo systemctl restart ssh重启服务但若/etc/ssh/sshd_config中PasswordAuthentication设为yes而PermitRootLogin是prohibit-password此时 root 用户即使有密钥也无法登录——因为策略优先级高于密钥存在性。更隐蔽的是Ubuntu 20.04 默认启用UsePAM yes这意味着 PAM 模块如pam_faillock.so可能因多次失败登录而临时锁定账户此时ssh -v日志里只显示Authentication failed.根本不会提示“账户已被锁定”。所以这篇指南不叫“SSH 密钥入门”而叫“Ubuntu SSH 密钥全链路掌控”。它覆盖的不是“如何生成密钥”而是当你在 VS Code 里点击“Connect to Host”却弹出Error: Failed to connect to server时你能像拆解一台发动机一样逐层检查密钥是否真被客户端选中服务端是否真在监听并接受该密钥系统是否允许该用户通过该方式登录文件权限是否让守护进程有权读取密钥每一个环节的验证方法、典型错误日志特征、以及绕过临时故障的诊断命令都会在这里展开。你不需要背诵所有参数但必须知道当连接失败时该看哪一行日志、该查哪个配置段、该执行哪条命令来定位根因。这才是真正能让你在凌晨三点快速恢复服务的能力。2. 密钥生成与管理别再用默认的 id_rsa理解算法、长度与存储位置的底层逻辑很多人生成密钥的第一反应是敲ssh-keygen回车到底结果得到一个id_rsaRSA 2048 位和id_rsa.pub。这在十年前或许勉强可用但在今天它既是安全短板也是后续排错的隐患源头。Ubuntu 22.04 的 OpenSSH 8.9p1 默认已弃用 RSA-SHA1 签名而id_rsa若未显式指定-b 4096生成的仍是 2048 位密钥其理论破解成本已低于 10^12 次运算——这对拥有 GPU 集群的攻击者而言并非遥不可及。更重要的是id_rsa这个文件名本身就是一个“弱约定”当你在 VS Code Remote-SSH 中配置多个主机时如果所有主机都用id_rsaVS Code 会默认尝试该密钥但一旦某台服务器禁用了 RSA如强制要求 Ed25519连接就会静默失败日志里只显示no mutual signature algorithm新手根本看不懂。2.1 算法选择Ed25519 是当前 Ubuntu 下的绝对首选OpenSSH 支持多种密钥算法RSA、DSA、ECDSA、Ed25519。其中Ed25519 是目前最推荐的选择原因有三性能碾压Ed25519 的签名和验证速度比 RSA 4096 快 10 倍以上。我在一台 i5-8250U 的笔记本上实测用time ssh -o ConnectTimeout1 -o BatchModeyes userlocalhost exit连接本地 SSH 服务使用id_ed25519平均耗时 0.012s而id_rsa_4096为 0.138s。对于需要频繁建立连接的自动化脚本或 VS Code 多窗口开发这差异直接体现为操作流畅度。安全性更高Ed25519 基于椭圆曲线Curve25519其 256 位密钥强度等效于 RSA 3072 位且不存在 RSA 的填充漏洞如 ROBOT 攻击。Ubuntu 20.04 的sshd默认启用KexAlgorithms中的curve25519-sha256与 Ed25519 密钥天然匹配。体积更小公钥文件仅 80 字节左右私钥约 300 字节远小于 RSA 4096 的 1.7KB 私钥。这在嵌入式设备或磁盘空间紧张的场景下是实打实的优势。生成命令应为ssh-keygen -t ed25519 -C your_emailexample.com -f ~/.ssh/id_ed25519_lab这里-t ed25519指定算法-C添加注释用于标识用途如邮箱或项目名-f指定文件名。我强烈建议为不同用途创建不同密钥id_ed25519_work公司服务器、id_ed25519_lab实验室、id_ed25519_personal个人 VPS。这样在~/.ssh/config中可精确指定每台主机使用的密钥避免冲突。2.2 密钥长度与密码短语安全与便利的黄金平衡点关于“是否设置密码短语passphrase”网上争论很多。我的结论很明确必须设置且要用强密码短语而非弱密码。理由如下无密码短语 私钥裸奔一旦你的笔记本硬盘被盗或被黑攻击者拿到id_ed25519文件就能立刻登录所有关联服务器。而带密码短语的私钥需先解密才能使用相当于给私钥加了一把物理锁。现代工具已解决输入负担Ubuntu 自带的gnome-keyring或kwallet可在首次输入后自动缓存密码短语。VS Code Remote-SSH 在连接时会调用系统密钥环你只需输一次之后整个会话期内无需重复输入。实测在 GNOME 桌面环境下首次连接后后续打开新终端或 VS Code 窗口完全无感知。密码短语的强度关键在于长度而非复杂度。一个 6 词的随机短语如correct horse battery staple比Pssw0rd!2024更难被暴力破解且更容易记住。生成这类短语可用pwgen -s -y -B 6 6需sudo apt install pwgen它会输出 6 组 6 字符的随机字符串挑一个组合成有意义的句子即可。2.3 存储位置与权限.ssh目录的 700 权限不是摆设密钥文件的存储位置和权限是 Ubuntu SSH 认证链中最易被忽视的一环。OpenSSH 客户端ssh命令在查找密钥时遵循严格路径规则首先检查-i参数指定的路径其次按顺序扫描~/.ssh/id_ed25519,~/.ssh/id_rsa,~/.ssh/id_dsa等默认路径最后才尝试~/.ssh/identity已废弃。因此将密钥放在~/.ssh/下是最佳实践。但更重要的是权限~/.ssh目录必须为700即drwx------否则ssh会拒绝读取任何密钥报错Permissions for /home/user/.ssh are too open.。这是因为如果目录可被组或其他用户写入恶意程序可能替换你的authorized_keys文件。私钥文件如id_ed25519必须为600-rw-------公钥id_ed25519.pub可为644-rw-r--r--但authorized_keys文件在服务端也必须是600。验证命令# 检查 .ssh 目录权限 ls -ld ~/.ssh # 应输出drwx------ 2 user user 4096 Apr 10 10:00 /home/user/.ssh # 检查私钥权限 ls -l ~/.ssh/id_ed25519 # 应输出-rw------- 1 user user 399 Apr 10 10:00 /home/user/.ssh/id_ed25519 # 一键修复权限谨慎使用 chmod 700 ~/.ssh chmod 600 ~/.ssh/id_*提示如果你在 WSL2 中使用 Ubuntu还需额外注意 Windows 文件系统挂载点的权限问题。WSL2 默认将 Windows 盘符挂载为/mnt/c其文件权限由 Windows ACL 控制chmod命令无效。因此绝不要将 SSH 密钥存放在/mnt/c/Users/xxx/.ssh/下必须放在 WSL2 的原生 Linux 文件系统内如/home/user/.ssh/否则ssh会因无法正确解析权限而拒绝使用。3. 服务端配置深度解析sshd_config中那些被忽略却决定成败的关键参数客户端密钥生成得再完美若服务端sshd_config配置不当一切皆为空谈。Ubuntu 的/etc/ssh/sshd_config文件长达 200 多行但真正影响密钥认证的核心就那么 5-6 个参数。很多人习惯性地sudo nano /etc/ssh/sshd_config找到PubkeyAuthentication yes就以为万事大吉却不知其他参数的默认值或注释状态正在默默阻断你的连接。3.1PubkeyAuthentication与AuthenticationMethods开启密钥认证只是第一步PubkeyAuthentication yes确实是启用密钥认证的开关但它只表示“允许使用公钥认证”并不保证“只使用公钥认证”。Ubuntu 默认还开启了PasswordAuthentication yes这意味着即使你配置了密钥SSH 服务仍会向客户端提供密码认证选项。这在安全上是巨大风险尤其当你的服务器暴露在公网时。正确的做法是双管齐下禁用密码认证将PasswordAuthentication yes改为no。强制多因素认证可选但推荐Ubuntu 22.04 支持AuthenticationMethods可要求同时满足密钥和密码或密钥和 TOTP。例如# 要求必须通过公钥 AND 密码认证 AuthenticationMethods publickey,password # 或者公钥 AND Google Authenticator需额外安装 libpam-google-authenticator AuthenticationMethods publickey,keyboard-interactive:pam_google_authenticator这样即使私钥泄露攻击者仍需第二因素极大提升安全性。3.2AuthorizedKeysFile路径错误是Permission denied (publickey)的头号元凶这是最常被忽略、也最致命的参数。它的作用是指定服务端查找用户公钥的文件路径。Ubuntu 18.04 及更早版本默认值是.ssh/authorized_keys即在用户主目录下的.ssh子目录中查找authorized_keys文件。但自 Ubuntu 20.04 起OpenSSH 升级到 8.2p1sshd_config中该行被注释并新增了%u占位符#AuthorizedKeysFile .ssh/authorized_keys # 新增的默认行为在源码中硬编码 # AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2更关键的是新版sshd会将%u解析为用户名并尝试在/etc/ssh/下查找authorized_keys。如果你手动取消注释并写成AuthorizedKeysFile .ssh/authorized_keys %u那么sshd会去/etc/ssh/user而不是/home/user/.ssh/authorized_keys找文件这显然不存在导致认证失败。正确配置永远是AuthorizedKeysFile .ssh/authorized_keys并且确保该文件存在于每个用户的~/.ssh/目录下且权限为600。你可以用以下命令批量检查# 检查所有用户的 authorized_keys 文件是否存在且权限正确 for user in $(cut -d: -f1 /etc/passwd | grep -E ^[a-z]); do auth_file/home/$user/.ssh/authorized_keys if [ -f $auth_file ]; then perm$(stat -c %a $auth_file 2/dev/null) if [ $perm ! 600 ]; then echo WARN: $auth_file has wrong permissions ($perm), should be 600 fi else echo MISSING: $auth_file for user $user fi done3.3AllowUsers/AllowGroups与DenyUsers访问控制的隐形闸门sshd_config中的访问控制列表是比防火墙更精细的“第一道门”。AllowUsers指定哪些用户可以登录AllowGroups指定哪些组的成员可以登录。如果你的服务器上有admin、dev、test多个用户但只想让admin和dev组的成员通过 SSH 登录应配置AllowGroups dev admin # 或者精确到用户 AllowUsers admin dev_user如果未配置AllowUsers或AllowGroups则默认允许所有有效用户登录。但一旦你配置了其中一项所有未被显式允许的用户都将被拒绝无论其密钥是否正确。这就是为什么有时你确认密钥无误、sshd_config语法正确却仍收到Permission denied的原因——很可能你用的用户名不在AllowUsers列表里。此外DenyUsers和DenyGroups是黑名单优先级低于Allow规则。例如AllowUsers admin DenyUsers guest此时admin可以登录guest被拒绝其他用户如dev_user也被拒绝因为AllowUsers已限制范围。3.4UsePAM与ChallengeResponseAuthenticationPAM 模块的双刃剑效应Ubuntu 默认启用UsePAM yes这意味着 SSH 认证流程会经过 Pluggable Authentication ModulesPAM系统。PAM 是 Linux 的通用认证框架它允许管理员插入各种认证模块如pam_faillock.so防暴力破解、pam_tally2.so登录计数、pam_google_authenticator.soTOTP。问题在于PAM 模块的失败会直接导致 SSH 认证失败且错误日志往往不明确。例如pam_faillock.so在/var/log/auth.log中记录pam_faillock(sshd:auth): User user not found in /var/run/faillock/user pam_faillock(sshd:auth): User user locked out.但ssh -v客户端日志只显示Authentication failed.。如果你没检查/var/log/auth.log就会误以为是密钥问题。另一个关键参数是ChallengeResponseAuthentication。它控制是否启用交互式挑战响应如键盘输入验证码。Ubuntu 默认为yes但如果你启用了AuthenticationMethods publickey,password此参数必须为yes否则密码认证环节无法触发。反之若你只想用密钥可将其设为no减少攻击面。4. 密钥分发与验证ssh-copy-id的真相、替代方案与authorized_keys文件的终极管理生成密钥后如何把它安全、可靠地放到服务器上ssh-copy-id是官方推荐工具但它绝非万能且在某些场景下会失效。理解其工作原理才能在它失灵时迅速切换到备用方案。4.1ssh-copy-id的工作流与三大失效场景ssh-copy-id的本质是通过现有认证方式密码或已有密钥将你的公钥追加到远程用户~/.ssh/authorized_keys文件末尾。其标准流程为使用ssh连接到目标主机如ssh userhost此时依赖你当前的认证方式通常是密码。在远程主机上执行mkdir -p ~/.ssh chmod 700 ~/.ssh创建目录。将本地~/.ssh/id_ed25519.pub的内容通过cat ~/.ssh/authorized_keys追加到远程文件。执行chmod 600 ~/.ssh/authorized_keys设置权限。这看似简单但三大常见场景会导致它失败场景一远程用户家目录在 NFS 或加密卷上如果/home/user挂载自 NFS 服务器且 NFS 服务端未启用no_root_squash那么ssh-copy-id以user身份执行chmod 600时NFS 会将user映射为nobody导致权限修改失败。此时authorized_keys文件权限为644sshd拒绝读取报错Authentication refused: bad ownership or modes for directory /home/user/.ssh。场景二远程~/.ssh目录由 SELinux/AppArmor 强制保护在启用了 SELinux 的 Ubuntu虽不常见但企业环境可能或 AppArmor 的系统中ssh-copy-id创建的~/.ssh目录可能缺少正确的安全上下文如ssh_home_t。sshd会因 SELinux 策略拒绝访问该目录日志中出现avc: denied { read } for ... commsshd name.ssh。场景三远程authorized_keys文件已存在且权限为644ssh-copy-id不会主动修复已有文件的权限它只负责追加内容。如果该文件权限错误后续所有密钥认证都会失败。4.2 手动分发三步精准控制规避所有陷阱当ssh-copy-id失效手动操作是最可靠的备选。以下是经过千次验证的三步法第一步安全传输公钥内容不要用scp传整个文件而是用cat输出并重定向避免权限继承问题# 在客户端执行假设公钥在 ~/.ssh/id_ed25519.pub cat ~/.ssh/id_ed25519.pub | ssh userhost mkdir -p ~/.ssh cat ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys这条命令将cat、mkdir、cat 、chmod串联在一条ssh命令中确保所有操作在远程同一 shell 会话中完成原子性高。第二步验证authorized_keys文件格式authorized_keys文件每一行是一个公钥格式为key_type base64_encoded_key comment。常见错误是复制时多了一个空格或换行。用以下命令检查# 在服务端执行 sed -n /^[^#]/p ~/.ssh/authorized_keys | head -n 1 | wc -c # 如果输出大于 1000说明该行可能包含多余空格或换行需手动编辑清理第三步强制重新加载 SSH 配置修改authorized_keys后无需重启sshd服务systemctl restart ssh会中断所有现有连接。只需发送SIGHUP信号让sshd重新读取配置和密钥文件sudo kill -HUP $(pgrep -f /usr/sbin/sshd -D) # 或更安全的 systemd 方式 sudo systemctl reload sshreload比restart更优雅它平滑地重新加载配置不影响已建立的连接。4.3authorized_keys的高级管理命令限制与环境变量注入authorized_keys文件的强大之处远不止于存储公钥。它支持在每行公钥前添加选项options实现精细化控制。这些选项用英文逗号分隔放在公钥字符串之前。例如限制命令执行防止密钥被用于任意命令只允许特定操作如 Git 推送command/usr/bin/git-shell -c \$SSH_ORIGINAL_COMMAND\,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... userhost此时该密钥只能执行git-shell无法启动交互式 shell。注入环境变量为特定密钥设置专属环境便于审计或路由environmentSSH_CONNECTION_TYPElab,no-user-rc ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... userhost连接后echo $SSH_CONNECTION_TYPE将输出lab。禁用特定功能增强安全性如禁用端口转发防止代理no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... userhost这些选项在~/.ssh/config的Host段中无法实现是authorized_keys独有的能力。它让一个密钥不再只是一个“钥匙”而是一个带有策略的“智能门禁卡”。5. 故障排查实战从ssh -v日志到journalctl构建完整的诊断链条当 SSH 密钥连接失败ssh -vverbose是你的第一把手术刀。但很多人只看到debug1: Trying private key: /home/user/.ssh/id_rsa就停住其实日志里藏着整条认证链的完整快照。下面我带你逐层解读ssh -v输出并关联服务端日志构建一个闭环诊断流程。5.1ssh -v日志的黄金三段论连接、密钥协商、认证ssh -v userhost的输出可分为三个核心阶段每个阶段都有标志性关键词阶段一TCP 连接与协议握手关键词debug1: Connecting to host [192.168.10.5] port 22.→debug1: Connection established.→debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6。失败征兆若卡在Connecting to...说明网络不通或防火墙拦截若出现Connection refused则是sshd服务未运行或监听端口错误检查sudo ss -tlnp | grep :22。阶段二密钥交换KEX与算法协商关键词debug1: kex: algorithm: curve25519-sha256→debug1: kex: host key algorithm: ecdsa-sha2-nistp256→debug1: kex: server-client cipher: chacha20-poly1305openssh.com MAC: implicit compression: none。失败征兆若出现no matching key exchange method found或no mutual signature algorithm说明客户端与服务端支持的 KEX 或签名算法无交集。解决方案是显式指定算法如ssh -o KexAlgorithmscurve25519-sha256 -o PubkeyAcceptedAlgorithmsssh-ed25519 userhost。阶段三用户认证Authentication关键词debug1: Next authentication method: publickey→debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:...→debug1: Server accepts key:→debug1: Authentication succeeded (publickey).失败征兆若卡在Offering public key...后无Server accepts key:说明服务端拒绝了该密钥。此时必须立即转向服务端日志。5.2 服务端日志/var/log/auth.log与journalctl的交叉验证Ubuntu 的 SSH 守护进程日志主要记录在/var/log/auth.log。当ssh -v显示Offering public key但未成功时立刻在服务端执行# 实时跟踪最新认证日志 sudo tail -f /var/log/auth.log | grep sshd # 或者用 journalctl 查看更详细的 systemd 日志 sudo journalctl -u ssh --since 2 minutes ago -f典型错误日志及对应根因auth.log日志片段根因分析解决方案sshd[1234]: User user from 192.168.10.10 not allowed because not listed in AllowUsers用户不在AllowUsers列表编辑/etc/ssh/sshd_config添加AllowUsers user然后sudo systemctl reload sshsshd[1234]: Authentication refused: bad ownership or modes for directory /home/user/.ssh~/.ssh目录权限不是700sudo chmod 700 /home/user/.sshsshd[1234]: Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keysauthorized_keys文件权限不是600sudo chmod 600 /home/user/.ssh/authorized_keyssshd[1234]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key/etc/ssh/下缺少主机密钥sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key然后sudo systemctl reload sshsshd[1234]: pam_faillock(sshd:auth): User user locked out.PAM faillock 模块锁定账户sudo faillock --user user --reset注意journalctl日志比auth.log更详细尤其当sshd启用了LogLevel VERBOSE时。可在/etc/ssh/sshd_config中临时添加LogLevel VERBOSE然后sudo systemctl reload ssh再复现问题journalctl将输出密钥指纹比对、PAM 模块调用等深层信息。5.3 VS Code Remote-SSH 的专属排错Remote-SSH: Show Log与配置文件校验VS Code 的 Remote-SSH 插件有自己的日志系统其排错路径与命令行ssh略有不同。当点击“Connect to Host”失败时打开 VS Code 命令面板CtrlShiftP输入Remote-SSH: Show Log选择对应主机。日志会显示插件内部调用的ssh命令、环境变量、以及它尝试的密钥路径。检查~/.ssh/config文件VS Code Remote-SSH 重度依赖此文件。一个典型的config条目如下Host lab-server HostName 192.168.10.5 User admin IdentityFile ~/.ssh/id_ed25519_lab IdentitiesOnly yes StrictHostKeyChecking no关键参数IdentitiesOnly yes强制ssh只使用IdentityFile指定的密钥忽略默认路径避免密钥混淆。StrictHostKeyChecking no在测试环境可跳过主机密钥确认但生产环境务必设为ask或yes。验证 VS Code 使用的 SSH 可执行文件VS Code 可能使用内置的 SSH 客户端而非系统ssh。在 VS Code 设置中搜索remote.ssh.path确认其指向/usr/bin/sshUbuntu 系统路径。若指向其他路径如 WSL2 内部路径需确保该路径下的ssh已正确配置密钥。6. 生产环境加固与自动化Ansible 脚本、密钥轮换与审计追踪在个人开发或小团队中手动配置 SSH 密钥尚可接受。但当服务器规模达到 10 台或涉及金融、医疗等合规场景时手动操作就成了灾难之源。此时必须引入自动化与审计机制将密钥管理从“艺术”变为“工程”。6.1 Ansible 自动化部署一份 Playbook 管理百台服务器Ansible 是 Ubuntu 环境下最轻量、最易上手的自动化工具。以下是一个生产级的setup-ssh-keys.ymlPlaybook它能为指定用户生成 Ed25519 密钥对将公钥安全分发到所有目标主机自动修正sshd_config关键参数重启服务并验证连接。--- - name: Secure SSH Key Setup for Ubuntu Servers hosts: ubuntu_servers become: yes vars: ssh_user: admin ssh_key_name: id_ed25519_prod ssh_key_comment: prod-deployment-{{ ansible_date_time.iso8601_basic_short }} tasks: - name: Ensure .ssh directory exists for user file: path: /home/{{ ssh_user }}/.ssh state: directory mode: 0700 owner: {{ ssh_user }} group: {{ ssh_user }} - name: Generate Ed25519 SSH key pair community.crypto.openssh_keypair: path: /home/{{ ssh_user }}/.ssh/{{ ssh_key_name }} type: ed25519 size: 256 comment: {{ ssh_key_comment }} owner: {{ ssh_user }} group: {{ ssh_user }} mode: 0600 register: ssh_key_result - name: Copy public key to authorized_keys lineinfile: path: /home/{{ ssh_user }}/.ssh/authorized_keys line: {{ ssh_key_result.public_key }} create: yes owner: {{ ssh_user }} group: {{ ssh_user }} mode: 0600 - name: Configure sshd for key-only auth lineinfile: path: /etc/ssh/sshd_config regexp: ^#?{{ item.key }} line: {{ item.key }} {{ item.value }} backup: yes loop: - { key: PubkeyAuthentication, value: yes } - { key: PasswordAuthentication, value: no } - { key: PermitRootLogin, value: no } - { key: AuthorizedKeysFile, value: .ssh/authorized_keys } - name: Reload SSH service systemd: name: ssh state: reloaded daemon_reload: yes - name: Verify SSH connection with new key command: ssh -o ConnectTimeout5 -o BatchModeyes -i /home/{{ ssh_user }}/.ssh/{{ ssh_key_name }} {{ ssh_user }}localhost exit args: executable: /bin/bash changed_when: false ignore_errors: yes运行此 Playbook 前需准备inventory.ini文件定义服务器列表并确保控制节点已安装ansible和community.cryptocollection。执行ansible-playbook -i inventory.ini setup-ssh-keys.yml即可在数分钟内完成百台服务器的密钥初始化。6.2 密钥轮换策略为何每年更换密钥是铁律以及如何零停机执行密钥不是“一次