【问题标题】：Using Chef & Amazon with a Non-standard ssh port使用带有非标准 ssh 端口的 Chef 和 Amazon
【发布时间】：2014-10-16 15:27:09
【问题描述】：

问题：如何在使用 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 时，该实例不可用。

【问题讨论】：

“为什么它不起作用？”是什么意思？你得到什么样的错误？调试输出？你是如何运行命令的？用这么少的信息很难回答这个问题……
@sethvargo 添加了额外的失败细节。基本上死在 Waiting for sshd..
这是一个 catch-22（双关语）。您将 SSH 端口设置为 999 并将 EC2 实例配置为执行相同的操作，但您使用的基础盒在端口 22 上配置了 SSHD。这听起来像是 EC2 方面的问题，因为我不确定如何Chef 可以帮助您，因为它只是使用 EC2 API 来制作实例......
不幸的是，这就是我的想法。 EC2 不允许您更改安全组，只能更改规则。因此，即使您在安全组中的 22 开始使用 SSH，然后在配置后更改为 999，您也必须手动将 22 重新添加到每个新实例的安全组，或者为每个实例创建一个新的安全组。呸。希望我错了，其他人有比这更好的主意。

标签： linux amazon-web-services ssh amazon-ec2 chef-infra

【解决方案1】：

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

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

解决方案 1：制作新的 AMI

创建一个将 sshd 配置为在 999 上侦听的新 AMI。完成此操作后，使用自定义 AMI 创建 EC2 服务器，一切正常。使用 cloudinit 有很多花哨的方法可以让您稍后自定义端口，但这似乎不值得付出努力。只需将“999”而不是“22”硬编码到 /etc/ssh/sshd_config

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

解决方案 2：Icky Icky 安全组

您可以通过在每次启动新服务器时修改安全组来解决此问题。只需添加一个例外，允许您的计算机在引导过程期间通过 SSH 进入该框，然后在完成后将其从您正在使用的安全组中删除。

这里的缺点是 EC2 中的安全组不是动态的，因此您要么必须为每台机器创建一个新的安全组（ick！），要么在运行期间为您的所有服务器上的工作站打开端口 22引导窗口（也 ick！）。

解决方案 3：隧道

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

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

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

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

【讨论】：