亚马逊的PuTTY连接AWS出现network error connection refused，终极解决方案。

使用PuTTY连接AWS的时候，一直出现network error connection refused。百度了这个问题，大家都说是SSH要设置成22。但是我已经设置过了，为什么还是遇到这个问题呢？

原来官方早已给了答案。大家看下边。

排查实例的连接问题

下面是在您尝试连接到实例时可能遇到的问题与错误消息。

内容

• 连接到您的实例时出错：连接超时
• 错误：服务器无法识别用户密钥
• 错误：未找到主机密钥，权限被拒绝 (publickey)，或者 身份验证失败，权限被拒绝
• 错误：未保护的私钥文件
• 错误：服务器拒绝我们的密钥或 没有支持的身份验证方法
• 在 Safari 浏览器上使用 MindTerm 时的错误
• 使用 Mac OS X RDP 客户端时出错
• 无法对实例执行 Ping 操作

有关 Windows 实例的更多帮助信息，请参阅Amazon EC2 用户指南（适用于 Microsoft Windows 实例）中的排除 Windows 实例的故障。

您还可以在 Amazon EC2 forum搜索答案和发布问题。

连接到您的实例时出错：连接超时

如果在连接到您的实例时看到以下错误消息：Network error: Connection timed out 或Error connecting to [instance], reason: -> Connection timed out: connect，请尝试以下选项：

• 检查您的安全组规则。您需要一个安全组规则，该规则允许适当的端口上来自公有 IP 地址的入站流量。

  1. 打开 Amazon EC2 控制台 https://console.aws.amazon.com/ec2/。

  2. 在导航窗格中，选择 Instances，然后选择您的实例。

  3. 在 Description 选项卡中的 Security groups 旁边，选择 view rules 以显示有效规则的列表。

  4. 对于 Linux 实例：验证是否有允许流量从您的计算机到端口 22 (SSH) 的规则。

     对于 Windows 实例：验证是否有允许流量从您的计算机到端口 3389 (RDP) 的规则。

     如果您的安全组具有允许来自单个 IP 地址的入站流量的规则，则当您的计算机在企业网络上，或当您通过 Internet 服务提供商 (ISP) 进行连接时，此地址可能不是静态的。请改为指定客户端计算机使用的 IP 地址的范围。如果您的安全组没有上一步中所述的允许入站流量的规则，请向您的安全组添加一个规则。有关更多信息，请参阅授权网络访问您的实例。

• [EC2-VPC]（我是这一步出错了）大家设置的时候，特别注意第五步与第六步。

• 
• 

• 查看子网的路由表。您需要一个路由来将目标在 VPC (0.0.0.0/0) 外的所有数据流发送到 VPC 的 Internet 网关。

  1. 打开 Amazon EC2 控制台 https://console.aws.amazon.com/ec2/。

  2. 在 Description 选项卡中，记下 VPC ID 和 Subnet ID 的值。

  3. 打开 Amazon VPC 控制台 https://console.aws.amazon.com/vpc/。

  4. 在导航窗格中，选择 Internet Gateways。验证是否有 Internet 网关连接到您的 VPC。如果没有，请选择 Create Internet Gateway 并按照指示创建一个 Internet 网关，选择此 Internet 网关，然后选择 Attach to VPC 并按照指示将其挂载到您的 VPC。

  5. 在导航窗格中，选择 Subnets，然后选择您的子网。

  6. 在 Route Table 选项卡上，验证带有 0.0.0.0/0 的路由是否为目的地，并验证您的 VPC 的 Internet 网关是否为目标。如果不是，请选择路由表的 ID (rtb-xxxxxxxx) 以导航到路由表的 Routes 选项卡，依次选择 Edit、Add another route，在 Destination 中输入 0.0.0.0/0，从 Target 中选择您的 Internet 网关，然后选择 Save。

• [EC2-VPC] 检查子网的网络访问控制列表 (ACL)。该网络 ACL 必须允许适当的端口上来自公有 IP 地址的入站和出站流量。默认网络 ACL 允许所有入站和出站流量。

  1. 打开 Amazon VPC 控制台 https://console.aws.amazon.com/vpc/。

  2. 在导航窗格中，选择 Your VPCs。

  3. 在 Summary 选项卡上，找到 Network ACL，选择 ID (acl-xxxxxxxx)，然后选择 ACL。

  4. 在 Inbound Rules 选项卡上，验证规则是否允许来自您的计算机的流量。如果不允许，请删除或修改阻止来自您的计算机的流量的规则。

  5. 在 Outbound Rules 选项卡上，验证规则是否允许到您的计算机的流量。如果不允许，请删除或修改阻止到您的计算机的流量的规则。

• 如果您的计算机在企业网络上，请询问网络管理员内部防火墙是否允许端口 22（对于 Linux 实例）或端口 3389（对于 Windows 实例）上来自您的计算机的入站和出站流量。

  如果您的计算机有防火墙，请验证其是否允许端口 22（对于 Linux 实例）或端口 3389（对于 Windows 实例）上来自您的计算机的入站和出站流量。

• 检查您的实例是否具有公有 IP 地址。如果没有，您可以将弹性 IP 地址与您的实例关联。有关更多信息，请参阅 弹性 IP 地址。

• 检查实例上的 CPU 负载，服务器可能已超过负载。AWS 自动提供数据，例如 Amazon CloudWatch 指标和实例状态，您可以使用这些数据查看实例上 CPU 的负载情况；如有必要，还可以调整负载的处理方式。有关更多信息，请参阅 使用 CloudWatch 监控您的实例。

  • 如果您的负载是可变的，您可以使用 Auto Scaling 和 Elastic Load Balancing 自动增加或减少实例。

  • 如果您的负载呈稳定增长的态势，您可以迁移到更大的实例类型。有关更多信息，请参阅调整您的实例大小。

错误：服务器无法识别用户密钥

如果您使用 SSH 连接到实例

• 请在连接时使用 ssh -vvv 获得三倍的详细调试信息：

  #ssh -vvv -i [your key name].pem ec2-user@[public DNS address of your instance].compute-1.amazonaws.com

  下列样本输出演示了如果您尝试使用服务器无法识别的密钥连接实例时您可能会看到的信息：

  open/ANT/myusername/.ssh/known_hosts).
  debug2: bits set: 504/1024
  debug1: ssh_rsa_verify: signature correct
  debug2: kex_derive_keys
  debug2: set_newkeys: mode 1
  debug1: SSH2_MSG_NEWKEYS sent
  debug1: expecting SSH2_MSG_NEWKEYS
  debug2: set_newkeys: mode 0
  debug1: SSH2_MSG_NEWKEYS received
  debug1: Roaming not allowed by server
  debug1: SSH2_MSG_SERVICE_REQUEST sent
  debug2: service_accept: ssh-userauth
  debug1: SSH2_MSG_SERVICE_ACCEPT received
  debug2: key: boguspem.pem ((nil))
  debug1: Authentications that can continue: publickey
  debug3: start over, passed a different list publickey
  debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
  debug3: authmethod_lookup publickey
  debug3: remaining preferred: keyboard-interactive,password
  debug3: authmethod_is_enabled publickey
  debug1: Next authentication method: publickey
  debug1: Trying private key: boguspem.pem
  debug1: read PEM private key done: type RSA
  debug3: sign_and_send_pubkey: RSA 9c:4c:bc:0c:d0:5c:c7:92:6c:8e:9b:16:e4:43:d8:b2
  debug2: we sent a publickey packet, wait for reply
  debug1: Authentications that can continue: publickey
  debug2: we did not send a packet, disable method
  debug1: No more authentication methods to try.
  Permission denied (publickey).

如果您使用 SSH (MindTerm) 连接到实例

• 如果未启用 Java，则服务器不会识别该用户密钥。要启用 Java，请参阅 Java 文档中的如何在 Web 浏览器中启用 Java？。

如果您使用 PuTTY 连接到实例

• 验证您的私有密钥 (.pem) 文件已经转换为 PuTTY (.ppk) 可以识别的格式。有关转换您的私有密钥的更多信息，请参阅 使用 PuTTY 从 Windows 连接到 Linux 实例。

  Note

  在 PuTTYgen 中，加载您的私有密钥文件并选择 Save Private Key (保存私有密钥) 而不是 Generate (生成)。

• 验证您在连接时是否对为 AMI 使用了正确的用户名称。在 PuTTY Configuration (PuTTY 配置) 窗口的 Host name (主机名) 框中输入用户名。

  • 对于 Amazon Linux AMI，用户名称是 ec2-user。

  • 对于 RHEL5 AMI，用户名称为 root 或 ec2-user。

  • 对于 Ubuntu AMI，用户名称是 ubuntu。

  • 对于 Fedora AMI，用户名称为 fedora 或 ec2-user。

  • 对于 SUSE Linux，用户名称是 root 或 ec2-user。

  • 另外，如果 ec2-user 和 root 无法使用，请与 AMI 供应商核实。

• 验证您的入站安全组规则允许入站流量进入合适的端口。有关更多信息，请参阅授权网络访问您的实例。

错误：未找到主机密钥，权限被拒绝 (publickey)，或者 身份验证失败，权限被拒绝

如果您使用 SSH 连接到实例并得到以下任一错误：Host key not found in [directory]、Permission denied (publickey) 或 Authentication failed, permission denied，请验证您使用了 AMI 的相应用户名称进行连接且 已为实例指定正确的私有密钥 (.pem) 文件。对于 MindTerm 客户端，在 Connect To Your Instance (连接到您的实例) 窗口中的 User name (用户名称) 框中输入用户名称。

正确的用户名如下所示：

• 对于 Amazon Linux AMI，用户名称是 ec2-user。

• 对于 RHEL5 AMI，用户名称为 root 或 ec2-user。

• 对于 Ubuntu AMI，用户名称是 ubuntu。

• 对于 Fedora AMI，用户名称为 fedora 或 ec2-user。

• 对于 SUSE Linux，用户名称是 root 或 ec2-user。

• 另外，如果 ec2-user 和 root 无法使用，请与 AMI 供应商核实。

请确认您使用的私有密钥文件对应于您启动实例时选择的密钥对。

1. 打开 Amazon EC2 控制台 https://console.aws.amazon.com/ec2/。

2. 选择实例。在 Description 选项卡上，验证 Key pair name 的值。

3. 如果您启动实例时没有指定密钥对，则可以终止实例并启动新实例，从而确保指定密钥对。如果这是您一直使用的实例，但您不再具有密钥对的 .pem 文件，则可以使用新的密钥对取代该密钥对。有关更多信息，请参阅 丢失私有密钥时连接到 Linux 实例。

错误：未保护的私钥文件

必须保护您的私钥文件，防止其他任何用户对其进行读写操作。如果除您外其他任何人都能够读取或写入您的私钥，则 SSH 会忽略您的密钥，并且您会看到以下警告消息。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '.ssh/my_private_key.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: .ssh/my_private_key.pem
Permission denied (publickey).

如果在尝试登录到您的实例时看到类似的消息，请检查此错误消息的第一行，验证您为实例使用的公钥是否正确。上面的示例对私有密钥 .ssh/my_private_key.pem 使用文件权限 0777，该权限允许任何人读取或写入该文件。此权限级别非常不安全，因此 SSH 会忽略此密钥。要修复此错误，请执行以下命令，替入您的私钥文件的路径。

$ chmod 0400 .ssh/my_private_key.pem

错误：服务器拒绝我们的密钥或 没有支持的身份验证方法

如果在使用 PuTTY 连接到您的实例时收到以下两种错误之一：Error: Server refused our key 或 Error: No supported authentication methods available，请验证在连接时是否为 AMI 使用了正确的用户名称。在 PuTTY Configuration (PuTTY 配置) 窗口的 User name (用户名) 框中输入用户名。

正确的用户名如下所示：

• 对于 Amazon Linux AMI，用户名称是 ec2-user。

• 对于 RHEL5 AMI，用户名称为 root 或 ec2-user。

• 对于 Ubuntu AMI，用户名称是 ubuntu。

• 对于 Fedora AMI，用户名称为 fedora 或 ec2-user。

• 对于 SUSE Linux，用户名称是 root 或 ec2-user。

• 另外，如果 ec2-user 和 root 无法使用，请与 AMI 供应商核实。

您还应验证您的私有密钥 (.pem) 文件已经正确转换为 PuTTY (.ppk) 可以识别的格式。有关转换您的私有密钥的更多信息，请参阅 使用 PuTTY 从 Windows 连接到 Linux 实例。

在 Safari 浏览器上使用 MindTerm 时的错误

如果您使用 MindTerm 连接到实例并且使用 Safari Web 浏览器，则可能会收到以下错误：

Error connecting to your_instance_ip, reason: 
 —> Key exchange failed: Host authentication failed

您需要更新浏览器的安全设置以允许 AWS 管理控制台在不安全模式下运行 JAVA 插件。

启用 JAVA 插件以便在不安全模式下运行

1. 在 Safari 中，保持 Amazon EC2 控制台打开，依次选择 Safari、Preferences、Security。

2. 选择 Plug-in Settings（在较旧版本的 Safari 上，选择 Manage Website Settings）。

3. 选择左侧的 Java 插件，然后在 Currently Open Websites 列表中找到 AWS 管理控制台 URL。从其关联列表中选择 Run in Unsafe Mode (在不安全模式下运行)。

4. 出现提示时，选择警告对话框中的 Trust。选择 Done 返回到浏览器。

使用 Mac OS X RDP 客户端时出错

如果您使用 Microsoft 网站的远程桌面连接客户端连接到 Windows Server 2012 R2 实例，则可能会收到以下错误：

Remote Desktop Connection cannot verify the identity of the computer that you want to connect to.

从 Apple iTunes 存储下载 Microsoft 远程桌面应用程序，然后使用该应用程序连接到实例。

无法对实例执行 Ping 操作

ping 命令是一种 ICMP 流量 — 如果您无法对实例执行 ping 操作，请确保您的入站安全组规则允许的 Echo Request 消息的 ICMP 流量来自所有资源，或来自从中发出命令的计算机或实例。如果您无法从实例发出 ping 命令，请确保您的出站安全组规则允许的 Echo Request 消息的 ICMP 流量发送到所有目标，或发送到您正在尝试对其执行 ping 操作的主机。