Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have an instance of an application running in the cloud on Amazon EC2 instance, and I need to connect it from my local Ubuntu. It works fine on one of local ubuntu and also laptop. I got message "Permission denied (publickey)" when trying to access SSH to EC2 on another local Ubuntu. It's so strange to me.

I'm thinking some sort of problems with security settings on the Amazon EC2 which has limited IPs access to one instance or certificate may need to regenerate.

Does anyone know a solution?

share|improve this question
8  
"It used to work before" -- before what? –  womble Jul 13 '09 at 8: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 stackoverflow.com/questions/4742478/… –  mikemay Sep 1 '13 at 7:09

13 Answers 13

up vote 77 down vote accepted

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?

share|improve this answer
    
@Greg how do I copy ssh private key from working PC to another PC on Ubuntu? –  Vorleak Chy Jul 14 '09 at 1:41
1  
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 2:03
2  
FYI you can use the -i flag to point to the path of the keys without installing them –  Jorge Vargas Nov 3 '10 at 23:35
13  
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 <keyfile> bitname@<ec2-address>. Unfortunately the -v option didn't help me find this, but it's still very useful to check! –  Matt Connolly Jan 20 '12 at 4:44
3  
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

As it hasn't been explicitly mentioned, sshd is by default very strict on premissions 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.

This will not show up with ssh -v, it'll show up in the logs emitted by sshd (typically put in /var/log/secure or /var/log/auth.log, depends on distro and syslogd configuration).

From man sshd(8):

 ~/.ssh/authorized_keys
         Lists the public keys (RSA/DSA) that can be used for logging in
         as this user.  The format of this file is described above.  The
         content of the file is not highly sensitive, but the recommended
         permissions are read/write for the user, and not accessible by
         others.

         If this file, the ~/.ssh directory, or the user's home directory
         are writable by other users, then the file could be modified or
         replaced by unauthorized users.  In this case, sshd will not
         allow it to be used unless the StrictModes option has been set to
         “no”.
share|improve this answer
4  
That "can be made writable" bit is what got me –  wmarbut Aug 14 '12 at 3:20
3  
FWIW the correct permissions for the key files are 600 (see here) –  Matt Lyons Nov 28 '12 at 4:22
1  
Yep, my .authorized_keys file was writeable by group so it refused to accept. –  aditya menon Aug 7 '13 at 8:45
    
I was beating my head against the wall! My user folder had the wrong permissions. Thank you! –  XJones Jun 12 at 23:19
1  
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 at 23:01

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.

share|improve this answer
1  
... this solved my particular problem. :) thanks for the reminder. –  Ian Jun 30 '10 at 19:35
11  
ssh host -l user is the same as ssh user@host, right? –  Znarkus Feb 1 '11 at 14:08
1  
@Znarkus yes, it is the same. –  Cawas Apr 19 '11 at 16:53
    
Yup, this solved my problem causing the "Permission denied (publickey)" error as well. –  Brooks Moses Jun 2 '11 at 21:30
    
This was the problem for me. I was expecting user "root" to work, but I was using an Ubuntu EC2 image which had the default user "ubuntu". –  Cerin Jun 14 '13 at 19:54

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.

share|improve this answer
    
Yeah... I was running the command with sudo, which is why it wasn't working. –  thaddeusmt Sep 17 '11 at 12:56

Something that's easier to read than ssh -i (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

share|improve this answer

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
share|improve this answer
    
That would make the server less secure. –  Znarkus Feb 1 '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

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

share|improve this answer
    
+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 1 '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 5 '13 at 7:14

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.

share|improve this answer
    
Thank you! This was exactly my problem. I didn't realize the DNS name changed when you restart an instance. –  Tim Swast Jan 2 '12 at 3:36
    
In my case, the *.compute.amazonaws.com URL changed when I assigned an elastic IP. –  Geoffrey Booth Jan 26 at 22:14

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.

share|improve this answer
2  
How to you resolve the issue? –  Julien Grenier May 15 '11 at 1:49

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.

share|improve this answer

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.

share|improve this answer

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!

share|improve this answer

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.

share|improve this answer

protected by Community Aug 29 '11 at 22:45

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.