Some time ago, I was asked to setup a public key authentication for SCP session betwen 2 *nix servers. The process should be straight forward, as mentioned on my previous post regarding this subject.
But somehow the login process keep on asking me to enter the correct password, and ignoring the public key that I have copied to the remote server. I start the process in verbose mode, so that I can get meaningful output that can help me solve the issue:
[surfer@kazekiri ~]$ ssh -v mach5@avenger
and this is snipped from the output that I get:
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/surfer/.ssh/identity
debug1: Trying private key: /home/surfer/.ssh/id_rsa
debug1: Offering public key: /home/surfer/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
This means the private key is recognized, and was offered as a mean for authentication by the local server, but somehow the login process still require me to type-in the password for the remote user.
After some reading, I found out the culprit was the access restriction to the key stored on each server. The login process requires that the private key (id_dsa) and the public key stored on the remote server (authorized_keys) are stored on a folder that can only be accessed by the corresponding users. So I need to do the following:
[surfer@kazekiri ~]$ chmod -R 700 .ssh
and, also on the remote server:
[mach5@avenger ~]$ chmod -R 700 .ssh
Aaand, voila! The public key authetication should works.
Thank you!! I’ve been frustrated with the reason why it tried the password method without finishing the publickey method…now it finally works!!
You’re welcome 🙂
Again, many thanks to you (and google). This was my problem too… cheers! -mt
Thank you for posting this. However I tried all this and it still didn’t work. It turns out (according to the SSH FAQ) that you must also have the correct permissions on the server $HOME directory. Changing them to remove ‘group’ and ‘other’ write permission (e.g. 640) fixed it.
p.s. oops, make that ‘750’ or chmod go-w $HOME
Thx for the info 🙂
thanks. the group permissions were holding me up.
Thanks for the detailed information.
I have tried all the above mentioned steps but ssh still asks for password.
I get the following message in the ssh verbose output
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pvarshneya/.ssh/id_dsa
debug1: read PEM private key done: type DSA
debug3: sign_and_send_pubkey
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
I think culprit here is ‘debug2: we did not send a packet, disable method’
But i don’t know how to fix it.
Have you tried to change the security to the authorized_keys file to 644 ?
Thanks, that cleared up my problem on a server I’d just rebuilt. I’d verified keys, verified the config matched other servers, etc… I was really dreading some sort of ‘generate a new key, test, propagate key change (rejections and new key) across GK-HowMany servers’ process that was going to be my move if teh Google hadn’t found your advice.
glad this solved your problem 🙂
Thanks!
🙂
i tried ‘chmod 644 authorized_keys’ but i’m getting “chmod: authorized_keys: Operation not permitted.”………..
plz help me solving this
OK. First, make sure that the authorized_keys file belong to you. To do that, login as root and do chown -R username. usergroup Authorized_keys
Or
If you use ubuntu, type: sudo chown -R username.usergroup authorized_keys. Replace username with your login, and usergroup with your login group.
Afterall that, redo the chmos command
Thank you..I have been trying this for last 4hours. This solved the issue 🙂
I couldnt catch up….when you say “by the corresponding user”…you mean the user root?
and if not root..why do you put the permisions on 700 ??
the corresponding user means the account that you use to ssh to the server. Let say in my case this is “surfer”. I need to chmod 700 the directory /home/surfer/.ssh to make sure that only the user “surfer” has access to that directory