灾备演练aws 跳板机 公钥 失效处理与快速恢复流程实战案例

【1】概述与目标

小分段1：背景 — 跳板机（Bastion）公钥失效会导致运维中断，影响应急响应与多环境访问。
小分段2：目标 — 在最短时间内恢复 SSH 访问、保证最小权限、记录步骤并完成演练复盘，确保可重复执行的恢复流程。

【2】确认问题与初步诊断

小分段1：验证症状 — 在本地执行 ssh -i mykey.pem ec2-user@BASTION_IP，记录错误（如 Permission denied (publickey)）。
小分段2：收集证据 — 登录 AWS 控制台查看 CloudTrail、CloudWatch Logs（/var/log/auth.log 或 /var/log/secure），确认是否为 authorized_keys 被篡改或公钥过期/删除。

【3】评估可用的访问替代通道

小分段1：优先使用 AWS SSM Session Manager（无需 SSH 密钥）。确认实例是否有 SSM Agent、实例配置了具有 AmazonSSMManagedInstanceCore 的 IAM Role。
小分段2：若 SSM 不可用，检查 EC2 Instance Connect 或是否有私有管理网络中的跳转机（另一个可以访问目标实例的主机）。

【4】通过 SSM 快速进入实例（推荐首选）

小分段1：准备 — 确认实例已附加 IAM Role 并且 SSM Agent 运行：aws ssm describe-instance-information。
小分段2：执行 — 控制台或 CLI 使用 aws ssm start-session --target instance-id 进入 Shell；进入后查看 /home/*/.ssh/authorized_keys 和 /var/log/auth.log，定位问题。

【5】EBS 挂载法修改 authorized_keys（无法直接登录时）

小分段1：步骤概览 — 停机→分离根卷→挂到救援实例→挂载→编辑 authorized_keys→卸载→重挂回原实例→启动。
小分段2：关键命令示例 — 停机：aws ec2 stop-instances --instance-ids i-xxxx；分离卷：aws ec2 detach-volume --volume-id vol-xxxx；在救援实例上 attach、sudo mkdir /mnt/rescue && sudo mount /dev/xvdf1 /mnt/rescue，编辑 /mnt/rescue/home/ec2-user/.ssh/authorized_keys（注意权限：chmod 600，chown ec2-user:ec2-user）。完成后逆序操作并启动原实例。

【6】使用 AWS Systems Manager 批量下发/替换公钥

小分段1：准备新公钥字符串，放入安全位置（Secrets Manager 或 SSM Parameter Store 加密）。
小分段2：使用 Run Command 批量写入示例：aws ssm send-command --document-name "AWS-RunShellScript" --targets "Key=tag:Role,Values=bastion" --parameters commands=["echo 'ssh-rsa AAAA... newkey' > /home/ec2-user/.ssh/authorized_keys","chown ec2-user:ec2-user /home/ec2-user/.ssh/authorized_keys","chmod 600 /home/ec2-user/.ssh/authorized_keys"]。确认命令执行结果并检查 exit codes 与输出日志。

【7】验证恢复与回归测试

小分段1：验证 SSH — 使用替换后的私钥从管理端尝试 ssh 连接，并在登录后检查 last、who 和 /var/log/auth.log。
小分段2：功能测试 — 通过跳板机访问内部目标实例，验证端口转发、代理链正常，确保业务访问路径恢复。

【8】演练后的固化与安全加固

小分段1：密钥轮换 — 将新公钥写入版本化存储，设定轮换策略（例如 90 天），并在 IAM/运维流程中加入审批。
小分段2：增强访问方式 — 优先启用 SSM Session Manager、限制 SSH 仅用于紧急情况，关闭网络级端口暴露，使用 Security Groups/IP 白名单与 MFA。

【9】脚本化与自动化建议

小分段1：编写恢复脚本 — 包含检测 authorized_keys 差异、自动触发 SSM Run Command 批量下发脚本、以及在 EC2 停机时自动创建快照的步骤。
小分段2：日志与审计 — 将恢复操作输出写入 CloudWatch Logs / S3 并生成事件（CloudWatch Events -> SNS）通知相关运维岗，便于事后复盘与合规。

【10】常见故障与排查要点

小分段1：权限问题 — authorized_keys 文件权限不当（应为600）或目录权限错误（.ssh 700）会导致拒绝；修复后重试。
小分段2：用户错误 — 确认公钥写入正确用户的 home 目录（ec2-user/ubuntu/centos）且 SELinux 上下文在启用时也需正确恢复（restorecon -Rv /home/...）。

【11】问：如果 SSM 未安装且无法停机拆卷，有无在线修复方法？

问：如果 SSM 未安装且无法停机拆卷，有无在线修复方法？

答：可以尝试利用同网络下的其他已登录主机作为跳板，使用 SSH 代理（ssh -A）或 scp 上传新公钥到目标实例的临时位置，然后通过已有的管理用户或脚本触发（若已有某自动化 agent 接收命令），否则需走 EBS 挂载或紧急停机流程。长期策略是确保 SSM 始终可用并启用 EC2 Instance Connect 作为备援。

【12】问：如何在演练中保证不误删现有公钥且可回滚？

问：如何在演练中保证不误删现有公钥且可回滚？

答：在替换前对 authorized_keys 做备份（cp authorized_keys authorized_keys.bak.TIMESTAMP 并上载至加密的 S3），使用版本化 SSM Parameter 或 Secrets Manager 存储新旧公钥，任何出错可通过 Run Command 或 EBS 挂载将备份文件恢复回去。演练脚本应包含自动备份与回滚命令。

【13】问：演练完成后有哪些必做的复盘与合规记录？

问：演练完成后有哪些必做的复盘与合规记录？

答：记录包括事件时间线、所用方法（SSM / EBS / Run Command）、执行命令与输出、故障原因分析、恢复时间（RTO）、所影响服务与用户、改进项与后续任务（如密钥轮换、AMIs 更新、监控规则）。将这些记录存入工单系统并归档到合规 S3 桶，安排复盘会议并更新灾备手册。

来源：灾备演练aws 跳板机 公钥 失效处理与快速恢复流程实战案例