228

I have an instance of an application running in the cloud on an Amazon EC2 instance, and I need to connect to it from my local Ubuntu. It works fine on one local ubuntu and also laptop. I got this message, Permission denied (publickey)., when trying to SSH to EC2 from a different local Ubuntu.

I'm thinking there may be problems with security settings on the Amazon EC2, which has limited IP access to one instance; or maybe a certificate needs to regenerate.

Does anyone know a solution to the Permission denied error?

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
Vorleak Chy
  • 2,421
  • 2
  • 15
  • 8
  • 12
    "It used to work before" -- before *what*? – womble Jul 13 '09 at 08:13
  • I have an Elastic Beanstalk EC2 instance. As at Aug-2013 the solution was to access the instance as the ec2-user user which made the Permission Denied (publicKey) error go away. Viz: ssh -i ./mike-key-pairoregon.pem ec2-user@ec2-some-address.us-west-2.compute.amazonaws.com. Of course you have to all the other stuff as per http://stackoverflow.com/questions/4742478/ssh-to-elastic-beanstalk-instance – mikemay Sep 01 '13 at 07:09
  • 4
    You get this issue if you have the wrong user name specified. The aws docs (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html) currently give an example with username ec2-user [ssh -i /path/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com], whereas my (old) ubuntu box has a username of ubuntu, so when I used the example I received this error, changing to the correct username resolves. – david.barkhuizen Jul 12 '16 at 16:21
  • @david.barkhuizen, your comment helped me. I had a similar problem; it turned out it had to do with the username. Thanks. – NaijaProgrammer Mar 23 '18 at 09:05
  • If someone is here for Bitnami WordPress, then 'bitnami' is the username which you have to use for SSH connection – Seeker Jan 03 '21 at 19:15
  • related: https://askubuntu.com/questions/311558/ssh-permission-denied-publickey – cellepo Aug 07 '21 at 19:48

17 Answers17

148

The first thing to do in this situation is to use the -v option to ssh, so you can see what types of authentication is tried and what the result is. Does that help enlighten the situation?

In your update to your question, you mention "on another local Ubuntu". Have you copied over the ssh private key to the other machine?

Greg Hewgill
  • 6,749
  • 3
  • 29
  • 26
  • @Greg how do I copy ssh private key from working PC to another PC on Ubuntu? – Vorleak Chy Jul 14 '09 at 01:41
  • 2
    I've copied over the ssh private key to the other machine as @Greg suggested. It works now. Thanks! – Vorleak Chy Jul 16 '09 at 02:03
  • 3
    FYI you can use the -i flag to point to the path of the keys without installing them – Jorge Vargas Nov 03 '10 at 23:35
  • 1
    This matter is probably moot by now, but Greg's answer (the first) is what actually did it for me, so perhaps someone can still benefit. The thing is that the command ssh-keygen -t rsa created a private key in ~/.ssh/id_rsa and the login procedure tries four files none of which is this one. Changing id_rsa to id_dsa did the trick. I would have never found out if it wasn't for the -v option. So thanks again Greg. Leen –  Jan 05 '11 at 14:07
  • 21
    In my case, I was using a bitnami .ami and didn't realise that you need to log in as the user called bitnami, like: `ssh -i bitname@`. Unfortunately the `-v` option didn't help me find this, but it's still very useful to check! – Matt Connolly Jan 20 '12 at 04:44
  • 7
    well, in my case i was using the wrong username. was using "ubuntu" instead of "bitnami". like this: ssh -i key.pem bitnami@hostaddress – Lucas Pottersky Apr 15 '12 at 21:44
  • in my case the keyhole.pub name didn't match "id_rsa.pub" – Nisba Dec 05 '16 at 14:14
  • 3
    A good lead is also the remote node itself, look into `/var/log/auth.log`, sometimes you will see the following messages: `Authentication refused: bad ownership or modes for file /var/lib/jenkins/.ssh/authorized_keys` or something else – Jonas Libbrecht Jan 31 '17 at 09:11
  • or /var/log/secure on Centos/RH. In my case "not allowed because not listed in AllowUsers" on a server I set up. – Code Abominator Feb 06 '17 at 23:59
  • 2
    This is something of an old thread, but it's worth mentioning here that you should NOT move private keys around. The idea with private keys is that they remain private and, unless you're transferring them manually via a USB thumb drive or something, you should NOT transfer the private key. Better would be to generate a new private key on the "other local ubuntu" box and add the public key to the machine you're SSH'ing to. – Ramy Mar 08 '17 at 20:38
  • As suggested by @JonasLibbrecht about checking remote logs. It did help. Thanks. But for other centos users like me its /var/log/secure – raevilman Jul 25 '19 at 10:12
81

As it hasn't been explicitly mentioned, sshd is by default very strict on permissions on for the authorized_keys files. So, if authorized_keys is writable for anybody other than the user or can be made writable by anybody other than the user, it'll refuse to authenticate (unless sshd is configured with StrictModes no)

What I mean by "can be made writable" is that if any of the parent directories are writable for anybody other than the user, users permitted to modify those directories can start modifying permissions in such a way that they can modify/replace authorized_keys.

Furthermore, if the /home/username/.ssh directory is not owned by the user, and thus the user has no permissions to read the key you can run into problems:

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

Note that jane does not own the .ssh file. Fix this via

chown -R jane:jane /home/jane/.ssh

These sorts of filesystem permission issues will not show up with ssh -v, and they won't even show up in the sshd logs (!) until you set the log level to DEBUG.

  • Edit /etc/ssh/sshd_config. You want a line that reads LogLevel DEBUG in there somewhere. Reload the SSH server using the mechanism provided by the distro. (service sshd reload on RHEL/CentOS/Scientific.) A graceful reload will not drop existing sessions.
  • Try authenticating again.
  • Work out where your auth facility logs go and read them. (IIRC, /var/log/auth.log on Debian-based distros; /var/log/secure on RHEL/CentOS/Scientific.)

Much easier to work out what's going wrong with the debug output which includes filesystem permission errors. Remember to revert the change to /etc/ssh/sshd_config when done!

Jeff Atwood
  • 12,994
  • 20
  • 74
  • 92
Kjetil Joergensen
  • 5,854
  • 1
  • 26
  • 20
  • 5
    That "can be made writable" bit is what got me – wmarbut Aug 14 '12 at 03:20
  • 7
    FWIW the correct permissions for the key files are 600 (see [here](http://superuser.com/questions/215504/permissions-on-private-key-in-ssh-folder)) – Matt Lyons-Wood Nov 28 '12 at 04:22
  • 1
    Yep, my .authorized_keys file was writeable by group so it refused to accept. – Aditya M P Aug 07 '13 at 08:45
  • 2
    I was beating my head against the wall! My user folder had the wrong permissions. Thank you! – XJones Jun 12 '14 at 23:19
  • 4
    same goes for the ~/.ssh folder itself. you may get following error message: `Authentication refused: bad ownership or modes for directory` – Yevgeniy M. Jul 30 '14 at 23:01
  • // , Actually, I can verify that if any folder containing a folder containing... containing ~/.ssh/ has permissions less restrictive than 0700, it will respond with "permission denied (publickey...". For details on how to fix this, I can leave an answer, if anyone's interested. – Nathan Basanese Aug 27 '15 at 16:43
  • @NathanBasanese: "permission denied (publickey)" is essentially you didn't offer any keys it recognizes, so while one of those cases is indeed that sshd on the other end is refusing to use that key, it would also include that you simply don't have the appropriate key(s) on the client side. – Kjetil Joergensen Aug 27 '15 at 18:53
  • // , In this case, it did actually turn out to be a matter of the permissions on the home folder of the target user on the host running sshd. If any directory _containing_ ~/.ssh has permissions less restrictive than 0700, ssh will offer the same error. Do you think this is similar to Naftuli's answer below? – Nathan Basanese Sep 01 '15 at 16:45
  • @NathanBasanese I'm not exactly sure I understand your question. So I'll re-iterate. "Permission denied (publickey)" only means that it could not complete public key authentication. It's an error message generated by the client, all the server told the client is that it couldn't complete public key authentication, the server includes no hint as to why it couldn't complete. It's obtuse by design, just to avoid leaking any information to a potential adversary. – Kjetil Joergensen Sep 02 '15 at 01:01
  • You can remove all permissions with: find ~/.ssh -exec chmod go-rwx {} \; – shawnhcorey Jun 18 '16 at 13:53
  • The ownership of the files saved me. Thanks a lot! – lowercase00 Mar 27 '22 at 04:11
38

I received this error, because I forgot to add -l option. My local username was not the same as on the remote system.

This does not answer your question, but I got here looking for an answer to my problem.

htoip
  • 111
  • 5
pkmk
  • 481
  • 4
  • 3
20

I got this message on a new instance based off the Ubuntu AMI. I was using the -i option to provide the PEM but it was still showing the "Permission denied (publickey)".

My problem was that I wasn't using the correct user. By running the ssh with ubuntu@ec2... it worked like normal.

17

Something that's easier to read than ssh -v (in my opinion of course), is tail -f /var/log/auth.log. That should be run on the server you are trying to connect to, while attempting to connect. It will show errors in plain text.

This helped me solve my issue:

User [username] from xx.yy.com not allowed because none of user's groups are listed in AllowGroups

Jeff Atwood
  • 12,994
  • 20
  • 74
  • 92
Znarkus
  • 1,087
  • 2
  • 18
  • 32
11

Check your /etc/ssh/sshd_config file. There, find the line which says 

PasswordAuthentication no

That line needs to be modified to say yes instead of no. Also, restart the sshd server afterwards. 

sudo /etc/init.d/ssh restart
Sudipta Chatterjee
  • 463
  • 4
  • 8
  • 21
    That would make the server less secure. – Znarkus Feb 01 '11 at 13:45
  • This was the problem I had: I wanted to set up an account for another user, authenticating with just a password. I also wanted to be able to log in as myself from places where I didn't have my private key. – Daniel Apr 10 '11 at 22:28
  • 2
    How can we go to `/etc/ssh/sshd_config` - if we can't even get into the server ? – code-8 Jun 27 '15 at 12:50
  • To get into the server itself, you must use the PEM file that they gave out when you created the instance. The instructions go after that. – Sudipta Chatterjee Jun 29 '15 at 18:27
  • This worked for me, although restarting sshd required the following command: `sudo service sshd reload` – pacoverflow Oct 19 '18 at 19:23
7

Perhaps not relevant to the current poster, but might help others who find this when searching for answers to similar situations. Instead of letting Amazon generate the ssh keypair, I recommend uploading your own, standard, default public ssh key to Amazon and specifying that when you run an EC2 instance.

This lets you drop the "-i" type syntax in ssh, use rsync with standard options, and also lets you use the same ssh key across all EC2 regions.

I wrote an article about this process here:

Uploading Personal ssh Keys to Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys

Eric Hammond
  • 10,901
  • 34
  • 56
  • +1 Looked up this question exactly for this reason. – John Riselvato May 30 '13 at 18:36
  • i see this error in following your article. regions=$(ec2-describe-regions | cut -f2) Required option '-K, --private-key KEY' missing (-h for usage) – KashifAli Sep 01 '13 at 14:01
  • @KashifAli You'll want to set up the EC2 API command line tool credentials so you don't always have to pass the credentials on every command line. – Eric Hammond Sep 05 '13 at 07:14
5

Strangely, my problem turned out to be that the server had been restarted and it was issued a new DNS name. I was using the old DNS name. I know this sounds stupid but it took me a while to figure this out.

Patrick Collins
  • 51
  • 1
  • 1
2

If you're trying to connect to a CyanogenMod phone running Dropbear, you should run the following lines to make sure everything is all permission'd right:

chmod 600 /data/dropbear/.ssh/authorized_keys

or 

chmod 700 /data/dropbear/.ssh/authorized_keys # In case of MacOS X 10.6-10.8

and 

chmod 755 /data/dropbear/ /data/dropbear/.ssh

This fixed it for me, otherwise nothing can connect.

Naftuli Kay
  • 1,648
  • 6
  • 22
  • 43
2

If you're using CentOS 5, you may want to set StrictModes no in /etc/ssh/sshd_config. I'm sharing /home directory using NIS/NFS, and I set all the permissions correctly, but it always prompted me with the password. After I set StrictModes no, the problem disappeared!

Scott Pack
  • 14,717
  • 10
  • 51
  • 83
uichin
  • 21
  • 1
1

I was having the same problem even though I was supposedly following all the steps including

$ ec2-authorize default -p 22

However, I had started my instance in us-west-1 region. So the above command should also specify that.

$ ec2-authorize default -p 22 --region us-west-1

After this command I was able to ssh into the instance. I spent a little while before I realized the issue and hope this post helps others.

mgorven
  • 30,036
  • 7
  • 76
  • 121
Ajit Verma
  • 11
  • 1
1

I had the same problem, and after trying tons of solutions which failed to work i opened the SSH port on my router's firewall (my router's firewall control panel is a mess, so it's hard to tell what's going on). Anyway, that fixed it :)

Super bloody annoying that the error you get is Permission Denied, implying that there was some kind of connection made, grr.

chichilatte
  • 111
  • 2
1

Greg's answer explains how to trouble shoot it better, however the actual issue is that you have an ssh key set on one side of the transaction (the client), which is attempting public key authentication rather than password based authentication. As you don't have the corresponding public key on the EC2 instance, this won't work.

Cian
  • 5,777
  • 1
  • 27
  • 40
0

TL;DR - make sure you use the correct username - ubuntu/ec2-user/etc.

I'm using a bastion-host (ec2) which is Amazon Linux OS, (ec2-user), and tried to from the bastion-host to a private-host (ec2) which is Ubuntu 18.04 OS (ubuntu)

This might sound funny since you should know the username of the machine you're SSHing to, but since I SSH to multiple machines, sometimes I make those mistakes.

Meir Gabay
  • 111
  • 3
0

If your .ssh dir has more than 1 key (ex: an id_rsa.pub, and an id_ed25519.pub), try ensuring you are executing ssh with the <correct_key_file>, by explicitly adding its path as an arg (and while you're at it, may as well explicitly pass <correct_username> too):

ssh -i ~/.ssh/<correct_key_file> <correct_username>@<host_server_address>

The defaults being used without explicitly specifying, may not be correct.

cellepo
  • 125
  • 8
0

This is a rare case, but if you have selinux enabled and you are using nfs for directory with the authorized_keys (e.g. shared home directories), you'll need to either disable selinux (not recommended for security reasons, but you can temporarily disable it to see if this is causing the problem) or allow selinux to use nfs home directories. I'm not clear on the details, but this worked for me setsebool -P use_nfs_home_dirs 1

Reese
  • 148
  • 10
0

I've just experienced the same issue after inadvertently adding group write permissions to the users home directory.

I discovered this was the cause by running tail -f /var/log/secure on the machine and seeing the error Authentication refused: bad ownership or modes for directory /home/<username>.

Jacob Tomlinson
  • 353
  • 2
  • 4
  • 15