Troubleshooting Connecting to Your Instance

Troubleshooting Connecting to Your Instance

The following are possible problems you may have and error messages you may see while trying to connect to your instance.

Contents

• Error connecting to your instance: Connection timed out
• Error: User key not recognized by server
• Error: Host key not found, Permission denied (publickey), or Authentication failed, permission denied
• Error: Unprotected Private Key File
• Error: Server refused our key or No supported authentication methods available
• Error using MindTerm on Safari Browser
• Error Using Mac OS X RDP Client
• Cannot Ping Instance

For additional help with Windows instances, see Troubleshooting Windows Instances in theAmazon EC2 User Guide for Windows Instances.

You can also search for answers and post questions on the Amazon EC2 forum.

Error connecting to your instance: Connection timed out

If you try to connect to your instance and get an error message Network error: Connection timed out or Error connecting to [instance], reason: -> Connection timed out: connect, try the following:

• Check your security group rules. You need a security group rule that allows inbound traffic from your public IP address on the proper port.
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. In the navigation pane, choose Instances, and then select your instance.
3. In the Description tab, next to Security groups, choose view rules to display the list of rules that are in effect.
4. For Linux instances: Verify that there is a rule that allows traffic from your computer to port 22 (SSH).

For Windows instances: Verify that there is a rule that allows traffic from your computer to port 3389 (RDP).

If your security group has a rule that allows inbound traffic from a single IP address, this address may not be static if your computer is on a corporate network or if you are connecting through an Internet service provider (ISP). Instead, specify the range of IP addresses used by client computers. If your security group does not have a rule that allows inbound traffic as described in the previous step, add a rule to your security group. For more information, seeAuthorizing Network Access to Your Instances.

• [EC2-VPC] Check the route table for the subnet. You need a route that sends all traffic destined outside the VPC (0.0.0.0/0) to the Internet gateway for the VPC.
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. In the Description tab, write down the values of VPC ID and Subnet ID.
3. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
4. In the navigation pane, choose Internet Gateways. Verify that there is an Internet gateway attached to your VPC. Otherwise, choose Create Internet Gateway and follow the directions to create an Internet gateway, select the Internet gateway, and then choose Attach to VPC and follow the directions to attach it to your VPC.
5. In the navigation pane, choose Subnets, and then select your subnet.
6. On the Route Table tab, verify that there is a route with 0.0.0.0/0 as the destination and the Internet gateway for your VPC as the target. Otherwise, choose the ID of the route table (rtb-xxxxxxxx) to navigate to the Routes tab for the route table, choose Edit, Add another route, enter 0.0.0.0/0 inDestination, select your Internet gateway from Target, and then choose Save.
• [EC2-VPC] Check the network access control list (ACL) for the subnet. The network ACLs must allow inbound and outbound traffic from your public IP address on the proper port. The default network ACL allows all inbound and outbound traffic.
1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
2. In the navigation pane, choose Your VPCs.
3. On the Summary tab, find Network ACL, choose the ID (acl-xxxxxxxx), and select the ACL.
4. On the Inbound Rules tab, verify that the rules allow traffic from your computer. Otherwise, delete or modify the rule that is blocking traffic from your computer.
5. On the Outbound Rules tab, verify that the rules allow traffic to your computer. Otherwise, delete or modify the rule that is blocking traffic to your computer.
• If your computer is on a corporate network, ask your network administrator whether the internal firewall allows inbound and outbound traffic from your computer on port 22 (for Linux instances) or port 3389 (for Windows instances).

If you have a firewall on your computer, verify that it allows inbound and outbound traffic from your computer on port 22 (for Linux instances) or port 3389 (for Windows instances).

• Check that your instance has a public IP address. If not, you can associate an Elastic IP address with your instance. For more information, see Elastic IP Addresses.
• Check the CPU load on your instance; the server may be overloaded. AWS automatically provides data such as Amazon CloudWatch metrics and instance status, which you can use to see how much CPU load is on your instance and, if necessary, adjust how your loads are handled. For more information, see Monitoring Your Instances Using CloudWatch.

o    If your load is variable, you can automatically scale your instances up or down using Auto Scaling and Elastic Load Balancing.

o    If your load is steadily growing, you can move to a larger instance type. For more information, see Resizing Your Instance.

Error: User key not recognized by server

If you use SSH to connect to your instance

• Use ssh -vvv to get triple verbose debugging information while connecting:

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

The following sample output demonstrates what you might see if you were trying to connect to your instance with a key that was not recognized by the server:

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).

If you use SSH (MindTerm) to connect to your instance

• If Java is not enabled, the server does not recognize the user key. To enable Java, go toHow do I enable Java in my web browser? in the Java documentation.

If you use PuTTY to connect to your instance

• Verify that your private key (.pem) file has been converted to the format recognized by PuTTY (.ppk). For more information about converting your private key, see Connecting to Your Linux Instance from Windows Using PuTTY.

Note

In PuTTYgen, load your private key file and select Save Private Key rather than Generate.

• Verify that you are connecting with the appropriate user name for your AMI. Enter the user name in the Host name box in the PuTTY Configuration window.
• For an Amazon Linux AMI, the user name is ec2-user.
• For a RHEL5 AMI, the user name is either root or ec2-user.
• For an Ubuntu AMI, the user name is ubuntu.
• For a Fedora AMI, the user name is either fedora or ec2-user.
• For SUSE Linux, the user name is either root or ec2-user.
• Otherwise, if ec2-user and root don't work, check with the AMI provider.
• Verify that you have an inbound security group rule to allow inbound traffic to the appropriate port. For more information, see Authorizing Network Access to Your Instances.

Error: Host key not found, Permission denied (publickey), or Authentication failed, permission denied

If you connect to your instance using SSH and get any of the following errors, Host key not found in [directory], Permission denied (publickey), or Authentication failed, permission denied, verify that you are connecting with the appropriate user name for your AMI and that you have specified the proper private key (.pem) file for your instance. For MindTerm clients, enter the user name in the User name box in the Connect To Your Instance window.

The appropriate user names are as follows:

• For an Amazon Linux AMI, the user name is ec2-user.
• For a RHEL5 AMI, the user name is either root or ec2-user.
• For an Ubuntu AMI, the user name is ubuntu.
• For a Fedora AMI, the user name is either fedora or ec2-user.
• For SUSE Linux, the user name is either root or ec2-user.
• Otherwise, if ec2-user and root don't work, check with the AMI provider.

Confirm that you are using the private key file that corresponds to the key pair that you selected when you launched the instance.

1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. Select your instance. In the Description tab, verify the value of Key pair name.
3. If you did not specify a key pair when you launched the instance, you can terminate the instance and launch a new instance, ensuring that you specify a key pair. If this is an instance that you have been using but you no longer have the .pem file for your key pair, you can replace the key pair with a new one. For more information, seeConnecting to Your Linux Instance if You Lose Your Private Key.

Error: Unprotected Private Key File

Your private key file must be protected from read and write operations from any other users. If your private key can be read or written to by anyone but you, then SSH ignores your key and you see the following warning message below.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@         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).

If you see a similar message when you try to log in to your instance, examine the first line of the error message to verify that you are using the correct public key for your instance. The above example uses the private key .ssh/my_private_key.pem with file permissions of0777, which allow anyone to read or write to this file. This permission level is very insecure, and so SSH ignores this key. To fix the error, execute the following command, substituting the path for your private key file.

$ chmod 0400 .ssh/my_private_key.pem

Error: Server refused our key or No supported authentication methods available

If you use PuTTY to connect to your instance and get either of the following errors, Error: Server refused our key or Error: No supported authentication methods available, verify that you are connecting with the appropriate user name for your AMI. Enter the user name in the User name box in the PuTTY Configuration window.

The appropriate user names are as follows:

• For an Amazon Linux AMI, the user name is ec2-user.
• For a RHEL5 AMI, the user name is either root or ec2-user.
• For an Ubuntu AMI, the user name is ubuntu.
• For a Fedora AMI, the user name is either fedora or ec2-user.
• For SUSE Linux, the user name is either root or ec2-user.
• Otherwise, if ec2-user and root don't work, check with the AMI provider.

You should also verify that your private key (.pem) file has been correctly converted to the format recognized by PuTTY (.ppk). For more information about converting your private key, see Connecting to Your Linux Instance from Windows Using PuTTY.

Error using MindTerm on Safari Browser

If you use MindTerm to connect to your instance, and are using the Safari web browser, you may get the following error:

Error connecting to your_instance_ip, reason:

 —> Key exchange failed: Host authentication failed

You need to update the browser's security settings to allow the AWS Management Console to run the Java plugin in unsafe mode.

To enable the Java plugin to run in unsafe mode

1. In Safari, keep the Amazon EC2 console open, and choose Safari, Preferences,Security.
2. Choose Plug-in Settings (or Manage Website Settings on older versions of Safari).
3. Choose the Java plugin on the left, then locate the AWS Management Console URL in the Currently Open Websites list. Select Run in Unsafe Mode from its associated list.
4. When prompted, choose Trust in the warning dialog. Choose Done to return the browser.

Error Using Mac OS X RDP Client

If you are connecting to a Windows Server 2012 R2 instance using the Remote Desktop Connection client from the Microsoft website, you may get the following error:

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

Download the Microsoft Remote Desktop app from the Apple iTunes store, and use the app to connect to your instance.

Cannot Ping Instance

The ping command is a type of ICMP traffic — if you are unable to ping your instance, ensure that your inbound security group rules allow ICMP traffic for the Echo Requestmessage from all sources, or from the computer or instance from which you are issuing the command. If you are unable to issue a ping command from your instance, ensure that your outbound security group rules allow ICMP traffic for the Echo Request message to all destinations, or to the host that you are attempting to ping.