Permission denied (publickey) when SSH Access to Amazon EC2 instance [closed]

This error message means you failed to authenticate.

These are common reasons that can cause that:

Trying to connect with the wrong key. Are you sure this instance is using this keypair? Trying to connect with the wrong username. ubuntu is the username for the ubuntu based AWS distribution, but on some others it's ec2-user (or admin on some Debians, according to Bogdan Kulbida's answer)(can also be root, fedora, see below) Trying to connect the wrong host. Is that the right host you are trying to log in to?

Note that 1. will also happen if you have messed up the /home/<username>/.ssh/authorized_keys file on your EC2 instance.

About 2., the information about which username you should use is often lacking from the AMI Image description. But you can find some in AWS EC2 documentation, bullet point 4. : http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

Use the ssh command to connect to the instance. You'll specify the private key (.pem) file and user_name@public_dns_name. For Amazon Linux, the user name is ec2-user. For RHEL5, the user name is either root or ec2-user. For Ubuntu, the user name is ubuntu. For Fedora, the user name is either fedora or ec2-user. For SUSE Linux, the user name is root. Otherwise, if ec2-user and root don't work, check with your AMI provider.

Finally, be aware that there are many other reasons why authentication would fail. SSH is usually pretty explicit about what went wrong if you care to add the -v option to your SSH command and read the output, as explained in many other answers to this question.

---

In this case the problem arises from lost Key Pair. About this:

There's no way to change Key Pair on an instance. You have to create a new instance that uses a new Key Pair.

You can work around the problem if your instance is used by an application on Elastic Beanstalk.

You can follow these steps:

Access to AWS Management Console Open Elastic Beanstalk Tab Select your application from All Applications Tab From left side menù select Configuration Click on the Instances Gear In Server Form check the EC2 Key Pair input and select your new Key Pair. You may have to refresh the list in order to see a new Key Pair you're just created. Save Elastic Beanstalk will create for you new instances associated with the new key pair.

In general, remember you have to allow your EC2 instance to accept inbound SSH traffic.

To do this, you have to create a specific rule for the Security Group of your EC2 instance. You can follow these steps.

Access to AWS Management Console Open EC2 Tab From Instances list select the instance you are interested in In the Description Tab chek the name of the Security Group your instance is using. Again in Description Tab click on View rules and check if your Security Group has a rule for inbound ssh traffic on port 22 If not, in Network & Security menù select Security Group Select the Security Group used by your instance and the click Inbound Tab On the left of Inbound Tab you can compose a rule for SSH inbound traffic: Create a new rule: SSH Source: IP address or subnetwork from which you want access to instance Note: If you want grant unlimited access to your instance you can specify 0.0.0.0/0, although Amazon not recommend this practice Click Add Rule and then Apply Your Changes Check if you're now able to connect to your instance via SSH.

Hope this can help someone as helped me.

---

This is how I solved the problem

ssh -i <key> ec2-user@<ec2 ip>

---

I solved the problem just putting sudo before

sudo ssh -i mykey.pem myec2.amazonaws.com

But the proper solution is to change the ownership first, and then connect as a normal user as Janus Troelsen said below. In my case it would be:

chown wellington:wellington key.pem

---

Try using

sudo ssh -i mykey.pem ubuntu@<ec2_ip_public_dns>

OR

sudo ssh -i mykey.pem ec2-user@<ec2_ip_public_dns>

---

Another possible cause of this error:

When user's home directory is group writeable, the user cannot login.

(Reproduced on Ubuntu instance.)

---

for the ubuntu 12.04 lts micro instance i had to set the user name as option

ssh -i pemfile.pem -l ubuntu dns

---

You need to do the following steps:

Open your ssh client or terminal if you are using Linux. Locate your private key file and change your directory. cd Execute below commands: chmod 400 .pem ssh -i .pem ubuntu@

If ubuntu user is not working then try with ec2-user.

---

I struggled with the same permission denied error apparently due to

key_parse_private2: missing begin marker 

In my situation the cause was the ssh config file of the current user (~/.ssh/config).

Using the following:

ssh -i ~/myKey.pem ec2-user@<IP address> -v 'exit'

The initial output showed:

debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config

... many debug lines cut here ...

debug1: Next authentication method: publickey
debug1: Trying private key: /home/ec2-user/somekey.pem
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

The third line above is where the problem actual was identified; however, I looked for at the debug message four lines from the bottom (above) and was misled. There isn't a problem with the key but I tested it and compared other configurations.

My user ssh config file reset the host via an unintended global setting as shown below. The first Host line should not have been a comment.

$ cat config
StrictHostKeyChecking=no
#Host myAlias
        user ec2-user
        Hostname bitbucket.org
#        IdentityFile ~/.ssh/somekey
#        IdentitiesOnly yes

Host my2ndAlias
        user myOtherUser
        Hostname bitbucket.org
        IdentityFile ~/.ssh/my2ndKey
        IdentitiesOnly yes

I hope someone else finds this helpful.

---

I forgot to add the username (ubuntu) when connecting my Ubuntu instance. So I tried this:

ssh -i /path/my-key-pair.pem my-ec2-instance.amazonaws.com

and the correct way was

ssh -i /path/my-key-pair.pem ubuntu@my-ec2-instance.amazonaws.com

---

This has happened to me multiple times. I have used Amazon Linux AMI 2013.09.2 and Ubuntu Server 12.04.3 LTS which are both on the free tier.

Every time I have launched an instance I have permission denied show up. I haven't verified this but my theory is that the server is not completely set up before I try to ssh into it. After a few tries with permission denied, I wait a few minutes and then I am able to connect. If you are having this problem I suggest waiting five minutes and trying again.

---

Here is a possible frustrating scenarios that produces this error:

If you are lunching a new instance from an AMI you created of another instance (say instance xyz), then the new instance will only accept the same key that instance A used. This is totally understandable but it gets confusing because during the step by step process of creating the new instance, you are asked to select or create a key (at the very last step) which will not work.

Regardless of the key you create or select, only the key you were using for instance XYZ will will be accepted by the new instance.

---

I struggled with this for a while too until I found the following:

eb ssh

When you use that from the project directory, bingo-bango no muss no fuss, you're in

---

In my own case, i did the following:

chmod 400 <key.pem>

ssh -i <key.pem> ec2-user@ec2_public_dns (for debian)

I was initially using root@ part and i got this prompt:

Please login as the user "ec2-user" rather than the user "root".

---

I'm in Windows with WinSCP. It works great on both File Explorer and PuTTY SSH Shell to access my Amazon EC2-VPC Linux. There is nothing to do with chmod pem file as it uses myfile.ppk converted by PuTTYgen from the pem file.

---

same thing happened to me, but all that was happening is that the private key got lost from the keychain on my local machine.

ssh-add -K

re-added the key, then the ssh command to connect returned to work.

---

This issue can be solved by login into Ubuntu box using below command:

ssh -i ec2key.pem ubuntu@ec2-public-IP

---

I've twice had keys and ssh command line correct (I know because I'm duplicating a working Ubuntu 14.04 instance), but just not been able to ssh into a new instance, even after waiting 5 minutes as suggested by Wade Anderson above.

I had to destroy and re-create the machine. This has happened on two separate occasions. Since I can't get in initially, I can't see what's wrong.

So, if you have this problem, try that.

---

you must check these few things:

Make sure your IP address is correct Make sure you are using the correct Key Make sure you are using the correct username, you can try: 3.1. admin 3.2. ec2-user 3.3. ubuntu

I had the same problem, and it solved after I changed username to ubuntu. In AWS documentation was mentioned to user ec2-user but somehow does not work for me.

---

My private key was set to permission 400 and was resulting in Permission denied setting it to '644' helped me .

key_load_private_type: Permission denied is the specific error I was getting

Solution: Sudo chmod 644 <key.pem>

Note: set to 644 is must, it was not working with 400

---

When you try doing

ssh -i <.pem path> root@ec2-public-dns

You get a message advising you to use the ec2-user.

Please login as the user "ec2-user" rather than the user "root".

So use

ssh -i <.pem path> ec2-user@ec2-public-dns

---

I had same problem and its very strange. If you believe you are doing all good than follow this: Some times there is confusion about user for the EC2 instance!! Some times you get ec2-user, ubuntu, centos etc. So check your username for the machie!!

Login with root user ssh -i yourkey.pem (400 permission) root@<ip> It will throw error and will give you the available username. then login with that user.

---

It's a basic thing, but always confirm which user you are trying to do the login. Im my case was just a distraction. I was trying using a root user:

ssh -i ~/keys/<key_name> root@111.111.111.111

But was another user:

ssh -i ~/keys/<key_name> dedeco@111.111.111.111

---

i had same error but different situation. to me it happened out of the blue after a lot of time i could ssh successfully to my remote computer out there. after a lot of searching the solution to my problem were file permissions. it is strange of course because i didn't change any permissions in my computer or the remote one belonging to the ssh's files/directories. so from the good archlinux wiki here it is:

For the local machine do this:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ecdsa

For the remote machine do that:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

after that my ssh started to working again without the permission denied (publickey) thing.

---

Another Possible Issue: Wrong login ID

Check 'Usage Instructions'

All good suggestions above, but what I ran into was that I selected a pre-made instance. After the instance has started , look at the usage instructions. I incorrectly used login id of the private key when in the instructions I was supposed to use 'bitnami' (e.g. bitnami@domain -i key.pem)

---

I had similar error

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: xxxx.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

My problem was that the instance did not start properly due to error on the run-on-start-up script from Step 3: Configure instance detail under Advanced details:

What I thought I entered:

#include
 https://xxxx/bootstrap.sh


What actually entered breaks the instance setup

#include

https://xxxx/bootstrap.sh

So the public key on instance side was not created

---

It's case sensitive.

Wrong : SSH EC2-user@XXX.XX.XX.XX -i MyEC2KeyPair.pem

Correct : SSH ec2-user@XXX.XX.XX.XX -i MyEC2KeyPair.pem

---

I was able to SSH from one machine, but not from another. Turns out I was using the wrong private key.

The way I figured this out was by getting the public key from my private key, like this:

ssh-keygen -y -f ./myprivatekey.pem

What came out didn't match what was in ~/.ssh/authorized_keys on the EC2 instance.

---

All of the top ranked answers above are accurate and should work for most cases. In the event that they don't as was in my case, I simply got rid of my ~/.ssh/known_hosts file on the machine I was trying to ssh from and that solved the problem for me. I was able to connect afterwards.

---