I'm going to answer my own question in case anyone else sees the same thing... Last night i had done:

ssh-add ~/.ssh/[keypair name]

then been connecting with:

ssh ec2-user@[ec2 instance ip]

This morning I tried the same and couldn't connect. But doing

ssh -i ~/.ssh/[keypair name] ec2-user@[ec2 instance ip]

gets me in.

Using ssh-add on the key pair again gets me in. I'm guessing ssh-add only works within the shell I'd issued it in. When I closed the terminal window and opened another I no longer had that keypair available without being explicit.

I ran into a similar problem and it turned out to be permissions on the home folder. Thankfully I still had another existing ssh connection open so I was able to check the log on the ec2 instance:

$ sudo less /var/log/secure

which contained:

Dec  9 05:58:20 ... sshd[29816]: Authentication refused:
bad ownership or modes for directory /home/ec2-user

This was fixed by issuing the command:

$ chmod og-rwx /home/ec2-user

I hope this helps out someone else.

Please note that after restarting the instance, the dns name changed. I fell for this several times. The keyfile was still valid, but the "servername" changed.

Make sure path to your private key is correct.

If your ssh client can not find the private key you are trying to provide, oddly enough it won't give you an error! it just won't use that key. It will use what ever key you have under .ssh/id_dsa and .ssh/id_ecdsa which of course will faint public key authentication.

This was happening for me because I wasn't using the right username. I was able to log in when using an AMI used in a tutorial I was following, but when I tried to use a different AMI (ubuntu + LAMP from Bitnami) I would get the Permission denied (public key). error. I finally realized that if I changed the username for the tutorial ami from ubuntu to ec2-user I would get the same error.

So a quick google tells that the username for Bitnami AMIs is bitnami. Problem solved.

I solved this by copying the contents of ~/.ssh/id_rsa.pub to ~/.ssh/authorized_keys on the EC2 instance.

This is specified in the documentation: http://docs.aws.amazon.com/opsworks/latest/userguide/security-ssh-access.html

Then I could ssh using this command:

ssh ec2-user@[ip.address]

Thank you!

I really appreciate @Trevor's answer here. I'm going to add this little trick that I now use to avoid this problem in the future.

Convenience

Because you have to create a different keypair for each availability zone, it becomes quite a hassle to manage them all and the commands that use them. With the proper setup in ~/.ssh/config my ssh command is as simple as:

ssh ec2-52-10-20-30.us-west-2.compute.amazonaws.com

That's the full public DNS of a server in the US West 2 availability zone. The proper username and key are selected because of this:

## ~/.ssh/config


Host *.us-west-2.compute.amazonaws.com
User ec2-user
IdentityFile ~/.ssh/bruno-bronosky-aws-us-west-2.pem

I spent the whole day searching internet for the answer. My issue exact the same. I fiddled with permission issue, changed back and forth, yet none solved my problem. After test with a new key and start/terminate a couple instances, finally I found it has to do with the same key name in different regions.

This is how "Permission denied (publickey)" happened to me:
1. Follow the practice book, select the us-east-1 as default zone
2. Create a key name "mykey"
3. Exploring AWS world by following examples in that book.
4. One day, try to test speeds of Sydney zone, switch to Sydney Zone as default on.
5. Create another key, named it as "mykey" without thinking, but not use it to connect through cli for a couple days.
6. Try to connect to AWS using cli.
7. Got "Permission denied (publickey)".
8. Spent many hours to debug ssh issue until I notice the key/zone issue.

Hope this could help newbie like me.

To avoid this issue, I think the best practice to name a key is to attach a region in it.

I also received: Permission denied.

I used :

ssh -v -i ~/.ssh/pemfile ec2-user@xx.xx.xx.xx

and the response was :

debug1: No more authentication methods to try.

Enter the command :

ssh-add -l

But the response was empty

So, I think the pen file has something wrong about format. Next, I found the pen file downloaded from ec2 web, and moved it over. Before this, I created a new file and parsed the text from the downloaded pem file to the directory ".ssh", then:

ssh-add filename

Which was successful.

If EC2 instance uses Ubuntu ami 14.04. Try adding 'ubuntu@' before the EC2 instance ip.

ssh -i [key name] ubuntu@[EC2 instance ip]

I changed the permissions to 600, although the permissions on the pem file were 644 already. And that worked :p hope it helps

Had the same problem, here is what you should do. First of all, if you have Windows, use the Babun command line, which is like the Linux one. Once you have that command line, open it and type ssh-i [key pair path] [username]@[EC2 public IP]. To find the path for the key pair, go to the file where your key is stored, hold shift and right-click and click copy path, and paste it in where the path goes in the command above. You probably will get "" marks on the outsides of the path you pasted, and \ backslashes. Delete the "" marks and replace the \ backslashes with regular slashes /. This worked in a situation like this that I had, best of luck to you.

Connecting to EC2 from cli is a little bit tricky at least for the first time. If you go to `

Services -> Compute -> EC2 -> Running Instances > and select the instance you want to ssh -> connect

` then you will see the dialog box describing how to connect to it. Part of it is shown below.

If you use number 4 without preceding it with ec2-user@ you will get

Permission denied (publickey).

Just copy and paste the one mentioned below in the `Example:.

In my case the reason for this was I had changed the permissions of the root directory folder with chmod. In AWS web site they describe a long way to change the permissions back with another temporary instance. However, I just terminated the old instance and launched another one and this time did not make any change to the permissions of the root directory and all is ok.

I had the same problem. What solved it for me was to place quotes around my directory and PEM file. I never had to do that in the past. I'm not sure why I was forced to do it this time. I have my PEM files in the same directory for other projects.

This is a common issue when we are dealing with ssh.

While one in on Mac or Linux based system, one can follow the following path:

1. Go to Location of Pem File
2. Open terminal there
3. Run following Command: chmod 400
4. And then use the Command to connect the server with ssh, and it will work fine.

But there is a problem with windows systems, as the chmod is not a command in cmd or Powershell.

To use ssh on windows, we have to follow the following process: (Note: This process only works on PowerShell and not in CMD. I would recommend using PowerShell in the Administrator model.)

Following are the steps:

1. Open Powershell in the Administrator Mode.
2. Go to the folder where pem file is kept.
3. RUN Following commands in sequence:

• Here name of Pem file is key.pem

  1. icacls.exe key.pem /reset // to revoke all privilegies

  2. icacls.exe key.pem /grant:r "$($env:username):(r)" // to grant all previous privilegies

  3. icacls.exe key.pem /inheritance:r // to remove all inheritacecs

Hope this will save your day.

This is a reference taken from the Following Link: CHMOD 400 in WINDOWS