Amazon EC2 – 重新启动后无SSH,连接被拒绝

我已经复制了这两三次,所以我猜测我在做什么是错的。

这是我的步骤:

  1. 通过EC2pipe理控制台启动新的实例:Ubuntu Server 13.10 – ami-ace67f9c(64位)
  2. 以默认值启动(使用我现有的密钥对)
  3. 实例启动。 我可以通过使用Putty或Macterminal进行SSH连接。 成功!
  4. 我重新启动实例
  5. 10分钟后,当实例应该备份并运行时,我的terminal连接显示:

    stead:~ stead$ ssh -v -i Dropbox/SteadCloud3.pem [email protected] OpenSSH_5.6p1, Op`enSSL 0.9.8y 5 Feb 2013 debug1: Reading configuration data /etc/ssh_config debug1: Applying options for * debug1: Connecting to 54.201.200.208 [54.201.200.208] port 22. debug1: connect to address 54.201.200.208 port 22: Connection refused ssh: connect to host 54.201.200.208 port 22: Connection refused stead:~ stead$ 

好吧,我知道公共IP地址可以更改,所以检查EC2pipe理控制台,我确认它是一样的。 奇怪的。 只是为了好玩,我尝试连接公共DNS主机名:ec2-54-201-200-208.us-west-2.compute.amazonaws.com。 没有骰子,相同的结果。

即使使用内置于EC2控制台的通过Java SSH客户端连接,我也会得到拒绝连接。

我检查了安全组。 这个实例在组启动向导-4中。 查看这个组的入站configuration,Port 22允许从0.0.0.0/0开始,所以应该在任何地方。 我知道我正在打我的实例,这是正确的安全组,因为我无法ping实例。 如果我为这个安全组启用了ICMP,突然之间我的ping就会通过了。

我在互联网上发现了一些类似的错误消息的其他职位,但似乎很容易通过调整防火墙设置解决。 我尝试了一些这些,没有运气。

我猜这是我错过的一个简单的EC2步骤。 感谢您的帮助,我很乐意提供更多信息或进一步testing!

更新 – 这是我的Amazon EC2控制台的系统日志: http : //pastebin.com/4M5pwGRt

今天在我的ec2实例上有类似的行为,并跟踪到这一点:当我做sudo reboot now机器挂起,我必须手动从awspipe理控制台sudo reboot时重新sudo reboot它重新启动就好了。 显然“现在”不是一个有效的重新启动选项,因为这里指出https://askubuntu.com/questions/397502/reboot-a-server-from-command-line

想法?

来自AWS开发者论坛的这个话题 :

尝试停止损坏的实例,分离EBS卷,并将其作为辅助卷附加到另一个实例。 一旦在另一个实例的某个地方挂载了损坏的卷,请检查/ etc / sshd_config文件(靠近底部)。 我有几个RHEL实例,其中Yum scrogged sshd_config在底部插入重复行,导致sshd在启动时由于语法错误而失败。

一旦你修好了,只要卸载音量,分离,重新连接到你的另一个实例,并重新启动它。

让我们来分析一下,并链接到AWS文档:

  1. 通过进入EC2pipe理控制台,单击“Elastic Block Store”>“Volumes”,右键单击与您停止的实例关联的卷, 停止损坏的实例并分离EBS(根)卷。
  2. 在与破损实例相同的区域和相同操作系统中启动一个新实例然后将原始EBS根卷作为辅助卷附加到新实例 。 下面的步骤4中的命令假定您将卷挂载到名为“data”的文件夹。
  3. 一旦在另一个实例上的某处挂载了损坏的卷 ,
  4. 通过发出以下命令来检查“/ etc / sshd_config”文件中的重复条目:
    • cd /etc/ssh
    • sudo nano sshd_config
    • ctrl-v一堆到达文件的底部
    • ctrl-k底部的所有行提到“PermitRootLogin without-password”和“UseDNS no”
    • ctrl-xY保存并退出编辑的文件
  5. @Telegard 指出(在他的评论) ,我们只是固定的症状。 我们可以通过注释“/etc/rc.local”文件中的3个相关行来修复原因 。 所以:
    • cd /etc
    • sudo nano rc.local
    • 寻找“PermitRootLogin …”行并删除它们
    • ctrl-xY保存并退出编辑的文件
  6. 一旦你修好了,只需卸下音量 ,
  7. 通过进入EC2pipe理控制台进行分离,单击“Elastic Block Store”>“Volumes”,右键单击与您停止的实例关联的卷,
  8. 重新连接到你的其他实例和
  9. 再次发射它 。

它可能无法帮助任何情况,但我已经看到一些EC2重新启动“卡住”的情况。 如果您在虚拟机上执行“重置”,然后回顾系统日志,则可能会改变行为。 确保日志来自第二次启动,而不是第一次启动 – 它们往往会延迟更新。

还有一件事要检查是确保实例在IP上响应。 你似乎正在得到一个连接拒绝上面,这听起来像实例已启动,但SSH没有运行或防火墙,但请确保实例已完全重新启动。

您也可以尝试打开testing系统中的所有端口,并查看“nmap”显示的内容 – 实例上是否有任何其他服务响应。

右键单击实例名称,然后单击“更改安全组”。 确保您创build的安全组允许从任何地方到端口22的任何人被选中并应用于此实例。

在运行Ubuntu 14.04的EC2服务器上通过SSH进行sudo reboot now后,我遇到了这个问题。 使用EC2pipe理控制台重新启动后工作良好。

在我的情况下,我会build立一个安全组,只允许从我的IP端口22连接。 几天后,我的ISP更改了我的IP地址,因此安全组需要更新。

我有一个类似的问题,运行sudo重启后,我的EC2 Amazon Linux实例无法访问。

没有SSH访问,从亚马逊pipe理控制台停止/启动/重新启动命令也没有给我结果。

我终于能够通过Amazon控制台创build一个映像来重启我的实例。 图像创build过程似乎修复了实例状态。

希望它有帮助;)

运行vanilla sudo reboot命令后,我遇到了同样的问题。 我发现我能够通过使用AWS控制台完全停止(不重新启动)AMI来解决问题,然后将其重新启动。

无论出于何种原因,从AWS控制台重新启动AMI,如同单击重新启动操作而不是停止然后启动实例,不能解决问题。

如上所述,你可能搞砸了/ etc / fstab /

我有这个问题。 首先,您必须像警告消息所述,在/ dev / sda1处重新添加卷。

然后我不能ssh。 我意识到我必须添加我创build的其他卷,并修复了ssh问题。

然后,您可以login并修复fstab回到原来的。