Permission denied (publickey).
Make sure you are using the correct EC2 key that was assigned to the instance or created when the instance was launched. You should have downloaded this key to your local machine. The key name is listed on the summary page for the EC2 instance:
Ensure that you have not changed the contents of the file in any way. Renaming it should be fine.
Change the permission of the key file so it is read only for the creator of the key by running this command:
chmod 400 your_key_file.pem
After you run this command you can type this command to verify the permissions of your file:
ls -al
If set correctly the permissions will look like this:
-rw-------@ 1 tradichel 1426935984 1692 May 18 21:00 your_key_file.pem
Make sure you have navigated to the directory where the key file is located or are using the correct path to the key in your ssh command:
ssh -i your_key_file.pem ec2-user@54.191.224.43
Make sure you have included the user name in your ssh command. The default username for an AWS linux instance is: ec2-user.
ssh -i your_key_file.pem ec2-user@54.191.224.43
Check that you are using the correct public IP address
If you have connected repeatedly to the same IP address that has used different EC2 keys over time, you may need to delete the existing key for the IP address from your known hosts file. You will see the location of your known hosts file if you run the ssh command with -vvv (verbose):
ssh -vvv -i your_key_file.pem ec2-user@54.191.224.43
The known hosts file location will look like this on a mac:
debug1: Found key in /Users/username/.ssh/known_hosts:2
You can simply delete the entire file or the offending entry.
Timeout
Make sure you have the following network configuration which will allow SSH traffic to reach your instance on port 22 and send responses back to the SSH client on ephemeral ports:
- The EC2 instance (virtual machine on AWS) is in a security group which allows port 22 ingress (inbound) from your local IP address
- The subnet NACL allows port 22 in and ephemeral ports out
- The route table on your subnet includes a route for an Internet Gateway.
- The EC2 instance has a public IP address.
- If your account is using a security appliance such as a Firebox Cloud make sure the rules are set up correctly to allow traffic through to your instance.
Random Failures with Active Directory and SSH
If you are using Active Directory as a means of connecting to an EC2 instance, there are a myriad of issues that may be occurring, often related to network ports. Active Directory requires a number of ports to work correctly and will differ depending on configuration. AD can dynamically determine which address to use based on DNS settings. If you find connections randomly failing likely there is something wrong with the network rules and some of the IP addresses in the corresponding DNS rules have been left out. When the connection works the connection randomly picked an address that has the rules set up properly. When the connection fails, the address randomly picked an address that was not set up properly. Additionally backhauling connections to a data center there may result in latency or other network problems along the way that cause failures. There are a variety of ways to architect Active Directory logins to overcome these problems, but in general, check that ALL the required addresses are allowed in your networking rules not just a subset.
