我公司的产品本质上是一台 Linux 机器（Ubuntu），位于别人的网络中，运行着我们的软件。到目前为止，我们在外地拥有的机器不到 25 台，并使用 TeamViewer 进行管理。
我们现在要发货 1000 个这样的盒子，TeamViewer 不再是一个选择。我的工作是想办法访问这些盒子并更新其中的软件。这个解决方案应该能够突破防火墙和其他一切。
我考虑过：
1. 本土解决方案（例如 Linux 服务）建立SSH 反向隧道到云中的服务器，以及云中的另一个服务，它会跟踪这些服务器并允许您连接到它们。
这显然需要大量劳动力，坦率地说，感觉就像在重新发明轮子，因为许多其他公司肯定已经遇到过这个问题。即便如此，我也不确定我们能否做得很好。
2. puppet、chef 或 OpenVPN 等工具
我尝试阅读尽可能多的资料，但似乎无法充分理解营销术语，从而理解显而易见的选择。
除了我们之外没有其他人需要连接这些盒子。有没有相关经验的人可以给我一些指点？
答案1
2022 年 6 月 - 更新
如果您需要的只是远程访问机器，那么可以使用以下两种较新的方法（如果您对 AWS 感到满意）：
- AWS SSM
- AWS VPN
尽管如此，我仍然会选择拉确保更新得到部署的机制。理想情况下，您只希望在紧急情况下使用这些直接 shell。否则，您（不可避免地）会得到一堆怪异的服务器，每个服务器都有自己有趣的配置调整，这些调整都是由某人在紧急情况下手动完成的，没有文档记录。
拉取更新，不要推送
随着规模的扩大，这将变得不可行推所有产品的更新。
- 你必须追踪每一个单个客户，每个客户可能都有不同的防火墙配置。
- 你必须创造传入通过客户防火墙的连接，这需要端口转发或其他类似的机制。这对您的客户来说是一个安全风险
相反，让您的产品定期“拉取”其更新，然后您可以在发展过程中在服务器端添加额外的容量。
如何？
这个问题已经按照你的建议解决了。以下是我能想到的几种方法。
使用 apt：使用带有自定义 PPA 和源列表的内置 apt 系统。如何设置 PPA？
- 缺点：除非你使用像 launchpad 这样的公共托管服务，否则设置你自己的 apt PPA + 打包系统不是一件容易的事。
使用 ssh：为每个产品生成一个 SSH 公钥，然后将该设备的密钥添加到您的更新服务器。然后，只需获取您的软件
rsync/scp所需的文件即可。- 缺点：必须跟踪（并备份！）您发出的每件产品的所有公钥。
- 专业版：比原始下载更安全，因为唯一可以访问更新的设备是安装了公钥的设备。
原始下载+签名检查：
- 将签名的更新文件发布到某处（Amazon S3、FTP 服务器等）
- 您的产品会定期检查更新文件是否更改，然后下载/验证签名。
- 反对意见：根据你部署的方式，这些文件可能会被公开访问（这可能会使你的产品更容易受到逆向工程和黑客攻击）
ansible：Ansible 是一款出色的系统配置管理系统工具。它属于 puppet / chef 领域，但无代理（使用 python）且设计为幂等。如果部署软件需要复杂的 bash 脚本，我会使用这样的工具来简化更新操作。
当然，还有其他方法可以做到这一点..但它让我想到了一个重要的观点。
签署/验证您的更新！
无论你做什么，至关重要的您有机制来确保您的更新没有被篡改。恶意用户可以在上述任何配置中冒充您的更新服务器。如果您不验证您的更新，您的盒子将很多更容易受到黑客攻击和入侵。
一个好方法是签署您的更新文件。您必须保留证书（或付费让某人这样做），但您可以在每台设备发货前在其上安装指纹，以便它们可以拒绝被篡改的更新。
物理安全
当然，如果有人能够物理访问客户的部署，他们就可以轻松接管服务器。但至少他们不能攻击其他部署！物理安全可能是您的客户的责任。
如果你能想象一下，如果你使用大型 OpenVPN 网络进行更新会发生什么……他们可能会使用受感染的服务器进行攻击VPN 上的每个实例
安全
无论你做什么，安全都是必须的内置从一开始就这样做。不要在这里偷工减料——如果你这么做，你最终会后悔的。
完全保护此更新系统超出了本文的范围，如果您或您团队中的某个人不了解此领域，我强烈建议您聘请顾问。这是值得的。
答案2
答案3
您真的需要访问它们吗？
或者只是更新它们？因为你可以让它们自行更新，类似于 apt 的无人值守更新方式。
如果你需要登录
为什么不用 OpenSSH 守护进程通过端口转发进行监听？每个客户都可以拥有单独的密钥以确保安全，并且只在需要时才连接。
由您的客户决定
您还需要考虑客户愿意接受什么。他们可能不习惯任何远程访问他们的网络，或者只习惯特定的技术/配置。