您需要自动化配置新机器——映像、软件包以及 AI 代理——但策略（或常识）要求在代理获得控制权前必须恰好一次人工签核。

IT 团队和 DevOps 工程师希望新机器能在无需人工陪同的情况下上线，但他们也需要一个可审计的单一时刻由人工验证构建。本指南展示了一种实用模式，用于自动化设备设置，从镜像部署到初始配置保持无人值守——只有一个人工签核的批准闸门。您将获得端到端的工作流、具体脚本和示例命令，以及在推广前需要了解的安全权衡。

设计目标

自动为机器进行配置（镜像、软件包、安装代理），无需任何交互提示。
在单次人工验证步骤完成之前，延迟网络访问和特权远程控制。
使该验证可审计、简短（单一决策），并且能抵抗远程篡改。
将运维开销降到最低 — 优先使用 Tenvo 托管的中继，除非书面合规要求强制使用自托管的替代方案（例如自托管的 RustDesk）。

高层流程：无人值守配置 + 一次批准

构建镜像 / cloud-init：安装操作系统更新，在可能的情况下启用 Secure Boot / TPM 证明，安装 Tenvo 客户端但不要自动批准。
启动时 cloud-init 以受限状态运行代理注册：设备以 UNAPPROVED 状态注册到管理后端，并在控制台或锁屏上显示一个简短的本地代码（6–8 位数字）。
操作员通过实地检查机器（或通过安全的带外电话）核对代码，并在管理控制台中批准设备——这是唯一一次人工签核。
批准后，后端签发设备证书/角色，并启用远程访问和管理策略。Tenvo 客户端切换到正常运行，可以通过直接 P2P 或托管中继连接。
所有操作都会生成审计事件（注册、批准、证书签发），并为合规目的保留。

为什么本地显示的代码是合适的单次签核方式

单点批准必须既简单又可靠。常见的模式是在设备首次启动时本地显示一次性代码。管理员检查物理设备（或受信任的远程摄像头）并在点击批准前将代码输入到控制台。这样可以保证有人确实看到了机器，并防止可能已经劫持了网络或镜像仓库的远程攻击者在未经物理检查的情况下自动注册设备。

实现模式和示例

在各种环境中方法相同：构建一个镜像，该镜像运行一个短的引导程序，向后端发送注册请求，并将自身标记为“未批准”，直到后端翻转一个'批准'位。下面是实用的构建模块。

1) 镜像 / cloud-init 示例（Linux）

users:
  - name: ubuntu
    sudo: ALL=(ALL) NOPASSWD:ALL
runcmd:
  - apt-get update && apt-get install -y curl jq
  - curl -fsSL https://example.com/bootstrap.sh | bash
# bootstrap.sh should install the Tenvo client and write /etc/tenvo/state=unapproved

2) Windows 无人值守安装程序（示例）

以静默方式运行 Tenvo 本机客户端 MSI 并将设备置于待处理状态。一个实际的 msiexec 示例：

msiexec /i TenvoClient.msi /qn TENVO_BOOTSTRAP=1 TENVO_REG_URL=https://relay.example.com/register

安装程序应创建一个小型服务，该服务发送注册请求并将本地确认码写入锁定的控制台或 Windows 登录屏幕（现场批准者可访问）。

3) 注册 API 和 UNAPPROVED 状态

当客户端注册时，不应立即获得完整权限。示例 JSON 有效负载（通过 TLS 发送到您的后端/relay）：

{
  "hwid": "SERIAL-1234",
  "os": "ubuntu-24.04",
  "pubkey": "-----BEGIN PUBLIC KEY-----...",
  "local_code": "582193"
}

后端将设备行记录为未批准，存储公钥，返回用于轮询的只读令牌，并向管理控制台发出警报。Tenvo 客户端保持在受限模式，拒绝远程控制会话直到获得批准。

4) 人工批准：唯一的审批关卡

管理控制台显示注册请求和设备的本地代码。操作员前往设备，验证该代码在设备本地显示，然后点击批准。该操作：

在后端将设备状态设置为已批准。
触发设备证书或角色令牌（短期）签发，客户端会去获取。
启用远程会话能力以及任何批准后配置任务（例如安装监控代理）。

5) 对最终凭证使用拉取而非推送

让客户端轮询批准结果，然后拉取其凭证，而不是由后端推送它们。这可以降低不安全回调的风险，并使流程更易通过 NAT / 防火墙。示例轮询间隔：前一分钟每 5 秒，然后指数回退至 30 秒；超时 24 小时。

操作脚本和示例

下面是本地引导服务的最小状态机（伪代码）：

# pseudo-steps for bootstrap service
if state == 'unregistered':
  send_enroll_request()
  store local_code
  state = 'pending'
while state == 'pending':
  resp = poll('/enroll/status')
  if resp.status == 'approved':
    fetch_credentials()
    state = 'approved'
    enable_remote_access()
  sleep(poll_interval)

安全和运营注意事项

TLS + 每台设备证书：使用由您的 CA 签发的每台设备证书的 TLS。当会话使用中继时，TLS 在中继处终止，中继运营商可以检查流量 — 请相应地规划审计和信任边界。
硬件信任根：尽可能使用 TPM 存储密钥并在注册时证明平台身份。TPM 绑定使设备冒充变得更难。
本地代码熵与显示：使用 6–8 位数字（足以避免随意猜测）并在锁定控制台上或设备附带的标签/相机视图上显示以便验证。
短批准窗口与轮换：使批准令牌短期有效，如果在 X 小时内未使用则要求重新批准。
审计日志：记录批准该设备的人、批准者的身份、时间戳、设备指纹，以及本地代码。根据您的合规策略保留日志。
事件处置：如果管理员注意到不匹配的序列号或可疑图像，请拒绝批准，将设备标记为隔离，并触发重建工作流。

为什么 Tenvo 的托管中继是推荐的默认选项

运营团队经常低估运行自建中继的成本：正常运行时间、补丁管理、密钥保管、证书续期和规模化机群。Tenvo 的托管中继（服务器位于德国）免去了大部分运维负担。Tenvo 为 macOS、Windows 和 Linux 提供原生客户端，提供处于公测的浏览器客户端，定价档位为 Free $0 / Lite $2.99/mo / Pro $7.99/mo。只有在书面要求强制时才选择自托管：如隔离网络、数据驻留规则或禁止使用第三方基础设施的合规性规定。如果必须自托管，请在决定前阅读自托管远程桌面：为什么、如何以及可能出现的问题。

可审计性：清晰记录单次签核

必须清楚记录那一道人工批准关卡。你的审计记录应包括：

设备指纹（型号、序列号、镜像哈希）
注册请求时间戳
显示的 Local_code 值
审批人身份及方式（SSO 身份、MFA 令牌）
批准时间戳及签发证书序列号

Tenvo 客户应将其与会话记录配合；有关合规性应捕获内容的示例，请参见远程桌面审计记录。

部署清单与实用说明

从 10–50 台机器的小规模试点开始，并要求审批时有人现场在场。
衡量从镜像启动到批准的时间，并以现场典型目标 < 5 分钟为准。
决定谁有权批准：基于角色的访问控制可降低风险（例如，只有配置工程师可以批准）。
为丢失或被盗设备实施证书撤销和远程擦除策略。
自动化批准后的配置任务（安装监控、应用防火墙规则），但将启用操作保持为单次手动点击。
如果需要用于 Windows 大规模部署的脚本化安装程序，请参阅我们在远程桌面 MSI 部署：通过 Group Policy 推送中的部署说明，了解实用的 MSI 建议。

边缘情况与注意事项

仅远程配置（无物理访问）：除非你拥有硬件证明，否则不要使用这种模式。仅远程批准较弱，因为你无法验证设备的实际物理占有。
镜像漂移：如果你重建镜像，请轮换你的签名密钥或更改指纹，以便审计追踪显示新的镜像哈希值。
中继可见性：请记住中继会解密 TLS；将中继运营者视为评估范围内的人员，并对敏感会话应用更严格的日志记录和保留规则。

1,000 台机器部署的示例时间线

试点 (2 周)：25 台机器，完善展示方式和审批 UX。
小规模部署 (4 周)：100 台机器，添加 RBAC 控制和日志保留策略，进行事故桌面演练。
全面部署 (8–12 周)：按站点分阶段；监控批准时间和支持工单。自动化报告以显示谁在何时批准了哪些设备。

何时自托管中继

仅当有明确的书面要求阻止使用第三方基础设施（例如法律、主权云义务或物理隔离网络）时，自托管中继才有正当理由。如果你自托管，必须为多区域故障切换、证书生命周期、日志保留以及安全运维负担预留预算。有关自托管时会出现哪些问题的背景信息，请阅读自托管远程桌面：为什么、如何以及会出现哪些问题。

自动化设备部署 — 单次人工审批的无人值守