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.

Okay, so I've been trying to connect to my EC2 instance, and I keep receiving the dreaded error: Permission denied (publickey). I know this has been asked a couple dozen times, but I have followed each and every reply I could find, to no avail. I am running a micro instance on EC2 attempting to SSH from an Ubuntu desktop. Here is the weird part. I was following this guide at Ubuntu.com, and it initially got me in. I got in, set up nginx and some other stuff. However, upon trying to reconnect after some time, I get the error above. I am using the following SSH command:

sudo ssh -v -v -i /home/user/.ec2/keypair.pem ec2-user@x.x.x.x

Keypair.pem is the private key that was created when I first created my instance, and was the one that I was using when I was able to successfully log in. The IP address is the address of the Elastic IP assigned to this instance (I've also tried the public DNS to no avail). I have the EC2 API tools installed, and I'm able to access information about my instance, so I believe that the certificates are correctly working. Here is another weird thing. When I try to connect using ec2-user, I just get the permission denied (publickey) error; however, when I try to connect as root (root@x.x.x.x), it says:

Authentication succeeded (publickey)

But then:

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

And then proceeds to kick me out. This would make me believe that the publickey is indeed correct, but I'm not sure. I've tried recreating the certificates again (not sure if that even helps), but no luck. In addition, I have heard about local permission problems, so I tried adjusting the permissions of the private key to 600 and 700, but that didn't touch the problem. If interested in the output of SSH, you can find it below:

OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to x.x.x.x [x.x.x.x] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/user/.ec2/keypair.pem type -1
debug1: identity file /home/user/.ec2/keypair.pem-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 134/256
debug2: bits set: 532/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 06:09:47:f7:46:55:8a:b1:9a:18:e4:46:b6:6d:88:7e
debug1: Host 'x.x.x.x' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug2: bits set: 505/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/user/.ec2/keypair.pem ((nil))
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ec2/keypair.pem
debug1: read PEM private key done: type RSA
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
share|improve this question
2  
I would probably edit this post to take away your root username and IP address. –  DKNUCKLES Aug 23 '11 at 17:47
add comment

2 Answers

First, why are you using sudo to execute ssh?

Second, try this instead:

sudo ssh -v -v -i /home/user/.ec2/keypair.pem -l ec2-user 107.20.201.235

share|improve this answer
    
Sorry, that was the result of trying the gamut of everything (I've tried both with and without). Yeah, I'm still getting the same thing with that command as well. So weird. –  naivedeveloper Aug 23 '11 at 18:18
    
Thanks for the help, but I couldn't get the issue resolved, so I ended up terminating the instance. –  naivedeveloper Aug 24 '11 at 12:38
add comment

When you ssh from A to B, you need a copy of the private key of the user you're ssh'ing from. You need the content of the public key in the .ssh/authorized_keys file in the home directory of the user you're ssh'ing to.

So for example, if you ssh from bob on machinea to fred on machineb, you need /home/bob/.ssh/some_key and /home/fred/.ssh/authorized_keys to contain a copy of bob's public key.

The fact that ssh to root works means the root user's home directory has the public key in it's authorized_keys file. The fact you can't connect to another user suggests it does not have a copy of the public key in it's authorized_keys file.

The sudo command only works because you're explicitly specifying a keyfile, normally you would run sudo as yourself because you can connect to any user from your account (even root) if you set the keys up correctly.

So, did you copy the public key contents into the authorized_keys file of the ec2-user on the target machine?

Or have you maybe generated a new key pair and are using the wrong private key?

share|improve this answer
    
Thanks for the help, but I couldn't get the issue resolved, so I ended up terminating the instance. –  naivedeveloper Aug 24 '11 at 12:38
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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