企业官网建设流程全解析

Time Capsule 出厂默认不开启 SSH，没有账号、没有 Web 管理入口，很多人以为只能把它当一台"砖头"路由器。开源项目 TimeCapsuleSMB（让 Apple AirPort Time Capsule 运行现代 Samba 的工具）给出了答案：固件里一直藏着 Apple 自己的 ACP 管理协议（端口 5009），只要用 AirPort 管理员密码，就能在不开机盖、不接控制台的条件下远程开启 SSH，并可靠地远程重启设备。本文解析它内置的纯 Python ACP 客户端是如何做到这一点的。

为什么 Time Capsule 没有 SSH 也能被管理 🤔

Time Capsule 运行的是 NetBSD 固件，它的设备管理入口其实一直存在——就是 AirPort 助理（AirPort Utility）背后那套ACP（AirPort Control Protocol）：

• 设备上的ACPd守护进程在TCP 5009端口监听，协议魔数为acpp；
• 认证方式简单直接：AirPort 管理员密码就是 ACP 密码；
• 设备状态和开关都以"属性"（4 字节名称）的形式读写，例如syUT（运行时长）、waMA（无线网卡 MAC）、dbug（调试开关）、acRB（重启请求）。

TimeCapsuleSMB 的作者在 src/timecapsulesmb/integrations/acp.py 中实现了一个仅依赖 Python 标准库的 ACP 客户端，覆盖握手、校验和（adler32）、属性读写、加密头生成等完整协议流程。正因为不需要额外依赖，configure才能在没有安装任何东西的裸机上直接用它开 SSH。

几个关键常量一眼看懂

开启 SSH 的完整流程：一次 ACP 调用 + 一次受控重启 🔓

SSH 的开启逻辑集中在 src/timecapsulesmb/services/acp_ssh.py 的enable_ssh_with_port_preflight中，流程比想象中更谨慎：

1. 端口预检（preflight）：对 5009 端口做最多 3 次、共 4 秒窗口的 TCP 探测。连不上时先判断"设备是不是换了 IP"，并给出你当前所在网段的信息，避免对着错误地址反复尝试；
2. 身份确认：通过 ACP 读出设备 MAC（waMA），如果这个 IP 上回答的是另一台 AirPort（比如它占用了你的目标地址），会主动放弃操作并沿 MAC 追踪到真正的位置——绝不修改错误的设备；
3. 写入开关：set_dbug(host, password, 0x3000)，即设置 ACP 属性dbug = 0x3000。注意此时 SSH 还没开，它要在下一次启动时生效；
4. ACP 重启：调用 src/timecapsulesmb/services/reboot.py 中的reboot_device，通过设置acRB = 0属性让 ACPd 保存配置并执行shutdown——和 AirPort 助理的重启走的是同一条路；
5. 等待并验证：轮询直到设备的syUT（运行时长）小于重启前读到的值，证明是新内核启动，再等 22 端口打开，最后回报 "SSH is configured"。

💡 整个流程不需要任何设备端配合：不上传脚本、不开后门，用的完全是 Apple 固件自带的正规通道。

远程重启：不只看"断线"，还要证明"真的重启了" 🔄

"发了重启命令、设备没反应"是老旧网络设备管理最常见的坑。TimeCapsuleSMB 的重启实现（services/reboot.py）为此设计了几重验证：

• 重启前读取基线：一次性读出syUT（运行秒数）和waMA（MAC），作为"新启动"的判据；
• 新启动判定：syUT明显小于"请求时刻 + 已等待时间"，才能断定设备真的重启过，而不是网络抖动；
• 防地址漂移：重启后设备可能拿到新的 DHCP 地址，代码会按 AirPort MAC 在全网重新定位设备（locate_airport），并把新地址回写给调用方；
• 防 ACPd 卡死：Apple ACPd 存在一个已知缺陷——接受了acRB请求、拆掉自己的服务，却永远没执行shutdown（详见 DETAIL.md 中 "Apple ACPd can hang during its own restart" 一节）。工具会在设备失联 90 秒后通过 SSH 检查内核 tick 计数和shutdown进程，连续两次确认 ACPd 沉默才报acpd_broken，并提示"未做任何修改"，避免把卡死的设备误判为重启失败后继续操作。

实际怎么用：命令行与配置流程 ✅

CLI 入口在 src/timecapsulesmb/cli/set_ssh.py，常用形态：

# 只查询：ACP 5009 和 SSH 22 是否可达 tcapsule set-ssh --status # SSH 关闭时：走 ACP 开 SSH + 自动重启 + 等待 22 端口 tcapsule set-ssh --enable # SSH 已开时：通过 SSH 执行 acp remove dbug 关闭，并重启验证保持关闭 tcapsule set-ssh --disable # 发送请求后立即返回，不等待重启验证 tcapsule set-ssh --enable --no-wait

更常见的是根本不用手动执行：首次运行tcapsule configure时，工具会自动探测 22 端口，发现关闭就走上面的 ACP 开 SSH 流程，重启、等 SSH 回来、再继续写配置和探测设备；密码错误时会重新询问而不是写出坏的配置文件（参见 DETAIL.md 的configure与set-ssh章节，以及 FAQ.md 中关于密码用法的说明）。macOS 图形客户端的 SSH 开关功能（Workflows/SSHAccessStore.swift）底层走的也是同一套服务。

关闭 SSH 有个细节值得注意：关闭走的是 SSH 内部执行设备自带的/usr/bin/acp remove dbug，并且必须再重启一次来验证"SSH 在新启动后依然保持关闭"——因为只看到端口关闭可能是误判，而运行时长重置才是重启的铁证。

适合了解这套机制的读者 📚

如果你正打算复活一台吃灰的 Time Capsule：

• 记住核心事实：没有 SSH ≠ 没有管理面，5009 端口的 ACP 才是 Time Capsule 的"管理总线"；
• TimeCapsuleSMB 的价值在于把 ACP 协议、身份确认、重启验证、故障判据都打包成了开箱即用的流程，你只需提供 AirPort 管理员密码；
• 想深入协议细节可以看 integrations/acp.py，想理解等待与验证策略看 services/reboot.py，命令行参数全表在 DETAIL.md 的set-ssh小节。

SSH 打开之后，部署 Samba、刷写启动钩子、跑 doctor 诊断等所有后续操作就都顺理成章了。