远程执行要划清三件事
远程执行的安全边界可以归结为三个问题：谁能发起连接、受管机上以什么身份执行、执行的代码从哪里来。推送式（控制端连接受管机）与拉取式（受管机主动取配置）在失败模式与暴露方向上有明显差异，但两者的共同点是——一旦控制端或配置源被攻破，影响范围就等于它管辖的全部主机。因此边界设计的目标是让「控制面失守」不至于直接等于「全部主机失守」。
基本信息
| 适用对象 | 推送式与拉取式两类远程执行架构 |
|---|---|
| 推送式特点 | 控制端保存凭据与密钥，受管机无需对外开放管理端口 |
| 拉取式特点 | 受管机主动取指令，控制面无需直连各主机 |
| 关键约束 | 执行身份范围、可达范围、代码来源可信度 |
| 审计要点 | 每次执行需可关联到发起者、批次与目标主机 |
边界要素
- 执行身份：尽量不使用最高权限身份，能免提权的任务不提权
- 可达范围：限制控制端能连接的主机集合，避免一个控制点覆盖全部资产
- 凭据分布：控制端持有的密钥影响面越大，越需要拆分与分域
- 代码来源：只执行来自受控仓库或签名校验通过的指令，拒绝来路不明的动态脚本
- 输出回传：执行结果常含主机信息与配置片段，回传通道与存储同样需要保护
- 中断处理：连接中断时任务可能停留在中间状态，需要有明确的重试与收敛方式
收窄边界的做法
收窄边界的做法
ssh-keygen -t ed25519 -f ~/.ssh/deploy_prod -C 'deploy-prod' # 按环境拆分密钥
cat >> ~/.ssh/config <<'EOF'
Host prod-*
User svcauto
IdentityFile ~/.ssh/deploy_prod
IdentitiesOnly yes
EOF
ssh -o BatchMode=yes -o StrictHostKeyChecking=yes prod-web01 true # 非交互校验，失败即暴露
ansible -i inventory --list-hosts 'prod:*' # 执行前先确认目标主机范围
ansible -i inventory prod -m ping --limit 'prod-web01' # 先单机试跑再全量两类架构对照
| 维度 | 推送式 | 拉取式 |
|---|---|---|
| 连接方向 | 控制端直连受管机 | 受管机主动向外取 |
| 暴露方向 | 受管机需开放访问入口 | 控制面需对外提供取用入口 |
| 凭据分布 | 集中在控制端 | 分布于受管机 |
| 失守后果 | 控制端被破即全量受影响 | 配置源被破即全量受影响 |
| 适用场景 | 内网集中运维 | 不可直连或需自治的环境 |
限制执行范围最直接的一步是限制控制端能连到哪些主机：即便控制端被攻破，攻击者也无法直接把影响扩散到范围外。这一点比事后检测更有效，也更容易验证。
动态下发并立即执行的脚本是远程执行里最难治理的一类：内容不可复现、无法回滚、审计上只能看到执行动作本身。需要临时下发时，应固定内容摘要并保留副本，确保事后能回答「究竟执行了什么」。