linux - 通过非标准 ssh 端口使用 Chef & Amazon

Question

问题:在使用 Amazon 安全组并使用 Chef 进行配置时，如何允许非标准端口上的入站 SSH 流量？

Amazon EC2:通过将此规则添加到安全组，允许端口 999 而不是 22 上的入站 ssh 流量。

Custom TCP Rule   Port Range: 999

Chef:通过以下方式在非标准端口上创建一个可以访问 ssh 的新服务器:

knife ec2 server create .... -p 999 ....

Ubuntu:通过编辑/etc/ssh/sshd_config 允许在非标准端口上进行 ssh 访问

Port 999 

够简单吗？为什么它不起作用？

当使用 knife ec2 server create ... -p 999 ... 实例创建时。但是它卡在“等待 sshd ...”上。最终出错了。使用 ssh -p 999 username@ip-address 或 ssh -p 22 username@ip-address 时实例不可用。

Answer 1

正如一些评论者所说，您被锁定是因为实例正在监听端口 22，但您的安全组只允许端口 999 上的 TCP 连接。 在此状态下无法连接到实例。

我可以看到这个问题的三种解决方案。

解决方案 1:制作新的 AMI

创建一个新的 AMI，将 sshd 配置为监听 999。 一旦你这样做了，使用你的自定义 AMI 创建你的 EC2 服务器，一切都应该工作。 有一些花哨的方法可以使用 cloudinit 来执行此操作，以便您稍后自定义端口，但这似乎不值得付出努力。 只需将“999”而不是“22”硬编码到/etc/ssh/sshd_config

明显的缺点是，对于您想要使用的任何新 AMI，您必须烘焙一个使用所需端口而不是 22 的新基础 AMI。 此外，这与在基本图像上分层配置的 Cheffy 理念背道而驰。

解决方案 2:Icky Icky 安全组

每次启动新服务器时，您都可以通过修改安全组来解决这个问题。 只需添加一个异常(exception)，允许您的机器在引导过程中通过 SSH 连接到盒子中，然后在完成后将其从您正在使用的安全组中删除。

这里的缺点是 EC2 中的安全组不是动态的，因此您要么必须为每台机器创建一个新的安全组(恶心!)，要么让这个在所有服务器上为您的工作站打开端口 22引导窗口(也很恶心!)。

解决方案 3:隧道

我能想到的最后一个选项是在您的实时服务器之间允许端口 22 上的连接。 然后，您可以连接到另一台服务器，打开 SSH 隧道(即 ssh -L ...)，然后通过隧道执行 knife ec2 操作，从而通过隧道连接。

或者，您可以在到达目标的途中手动通过其他服务器之一，而不是使用 knife 来引导新节点。

这里的缺点是您需要信任服务器的安全性，因为您必须执行一些代理转发或其他恶作剧才能成功连接到新节点。

这可能是我会选择的解决方案，因为它不需要新的 AMI，不向外界开放端口 22，并且新团队成员只需花费最少的精力就可以学会如何操作。