我希望能够对维护脚本进行编码以便根据需要远程运行。
编辑:好的用例:webhooks。例如,每当有人将代码推送到 github 时,就会触发 CI + 暂存部署。
如果我使用安全密码(例如 aes128 + 密码)加密 shell 命令:
例如'mysecretwords cd ~ && mkdir ./something' -> 'm4tpWsuiOJT0naKkyWDdNQUKMQ7',
然后允许通过 url 执行该命令:
例如'https://myserver.com/script/m4tpWsuiOJT0naKkyWDdNQUKMQ7‘
URL 本身包含在服务器上运行的编码命令,只有目标服务器才能使用密码对其进行解码。
我确信这是一个非常糟糕的想法:但出于兴趣如何确保?
提出这个问题的行为可能证明我对安全地做到这一点还不够了解。
答案1
首先让我们来解决你更重要的核心问题:
我希望能够对维护脚本进行编码以便根据需要远程运行。
这听起来像是一份工作(喇叭声) 自动化工具!
木偶立刻想到了这一点,但还有很多其他方法。
您还可以自己开发一个系统,使用无密码 SSH 密钥登录远程系统并在其上运行命令,这是在 puppet 等出现之前完成此类工作的一种历史悠久的方法。
现在让我们来谈谈你基于 HTTP 的想法——你直接说了:
我确信这是一个非常糟糕的想法:但出于兴趣如何确保这一点?
你是对的:它是一个糟糕的想法。不要在生产环境中执行此操作,尤其是当该 URL 可在 Big Bad Public Internet 上访问时。
请允许我详细叙述这些恐怖的事情:
- 您正在使用预共享密钥 (
mysecretwords
)。任何人都可以偷看(或猜测)此密钥并运行命令。 - 您正在使用隐蔽性来实现安全性(“没有人会知道这
https://myserver.com/script
是可以让您运行东西的 URL!”)。 - 您正在以 Web 服务器用户身份运行命令。
这可能不是您想要的,这意味着 Web 服务器用户需要具有某种提升的权限 - 以 root 身份运行、能够sudo
等。 - 您正在使用无状态协议(http)来运行可能需要终端、登录环境等的命令——这能可以完成,但执行任何除最琐碎的任务之外的任务都意味着您必须破解后端以维持状态。
- 你正在做
ssh
应该做的事情。
不要试图重新发明轮子。我保证你的椭圆形轮子不如圆形轮子(ssh
)。
如果你不能使用传统的 SSH,有很多基于 Web 的 SSH 客户端,甚至更多 Java 客户端。使用其中之一。您甚至可以将它们置于 HTTP 授权(用户名/密码、证书等)之后。
至于如何确保安全 - 您已经做了几乎所有可以做的事情:预共享密钥充当身份验证(组合用户名和密码)并提供一层加密,尽管这不是必需的。
https://
加密传输中的数据并消除了有人嗅探魔术 URL 的机会(尽管不是他们自己推断的机会)。
只要您的服务器仅允许通过https://
连接访问魔术 URL,并且您的 Web 服务器上的 SSL 配置是安全的,您就无法做得更好。
话虽如此,你为实现这一目标所付出的任何努力更多的安全并不能消除你正在尝试做的事情的根本缺陷——你可能永远侥幸逃脱,永远不会受到损害,但既然已经有工具可以做你想做的事,为什么还要增加一个你不需要的攻击面呢?(我想补充一下,这些工具都是由专家编写的,经过彻底的审查/测试其他专家,并且被广泛使用,因此如果出现安全问题,就会很快得到修复......)