Home / server / Questions / 39733
Accepted
Vorleak Chy
Asked: 2009-07-13 23:38:23 +0800 CST

Permission denied (publickey). SSH from local Ubuntu to Amazon EC2 server

  • 772

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?

linux amazon-ec2 ssh

17 Answers

  1. Best Answer

    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?

    • 148

  2. 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!

    • 81

  3. 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.

    • 38

  4. 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.

    • 20

  5. 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

    • 17

  6. 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
    • 11

  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

    • 7

  8. 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.

    • 5

  9. 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.

    • 2

  10. 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!

    • 2