问题:使用Amazon Security Groups以及同时使用Chef进行配置时，如何允许非标准端口上的入站SSH流量？
Amazon EC2:通过将此规则添加到安全组，允许端口999上的入站ssh流量，而不是22。
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使用。 最佳答案
正如一些评论者所说，由于实例正在侦听端口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)，该异常(exception)使您的计算机在引导过程中可以通过SSH进入框中，然后在完成后将其从正在使用的安全组中删除。
不利之处在于EC2中的安全组不是动态的，因此您必须为每台计算机创建一个新的安全组(请点击!)，或者在引导窗口中为所有服务器上的工作站打开此端口22(还好!)。
解决方案3:隧道
我想到的最后一个选项是允许实时服务器之间的端口22进行连接。
然后，您可以通过连接到另一台服务器，打开SSH通道(即ssh -L ...)，并通过该通道执行刀ec2操作来通过另一台服务器建立连接。
或者，您可以在到达目标的途中手动通过其他服务器之一，而无需使用刀引导新节点。
缺点是您需要信任服务器的安全性，因为必须成功执行一些代理转发或其他欺骗手段才能成功连接到新节点。
这可能是我会选择的解决方案，因为它不需要新的AMI，不需要开放22端口到外界，并且只需很少的精力就可以让新的团队成员学习如何做。