OpenSSH server refuses to accept key authentication

I tried to use public key authentication on my new server, and I came across this problem.

$ ssh -v -i .ssh/server 192.168.1.100
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data .ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.100 [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file .ssh/server type -1
debug1: identity file .ssh/server-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-1ubuntu3
debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.100' is known and matches the RSA host key.
debug1: Found key in .ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: .ssh/server
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

and then I have to input my password to get logged in.

But, if I already have one session connected to that server (which is connected by password), then the following connection uses key auth to avoid password input.

If there is no SSH connection already established, I can't connect without input password.

This is really weird to me, I checked the MD5 of /usr/sbin/sshd between the new server and the other normal server, it's the same. Then I just copied the /etc/ssh/sshd_config from the other normal server to the new server, and ran service ssh restart. The problem still exists.

How am I supposed to fix this?

Check that your .ssh folder and the files inside it on the client machine are only readable by the owner (chmod -R 600 .ssh) and that the owner is correct for the folder and files (use chown command if necessary).

Also check the authorized_keys folder and file on the server (probably in /root/.ssh or the home folder of the user trying to login) to make sure their permissions and owner are set in the same way.

Edit: based on more feedback (and some guesswork!) - can you check /etc/ssh/sshd_config and see whether the following parameter is set like below. If not, try editing it.

AuthorizedKeysFile /home/%u/.ssh/authorized_keys

Note, this assumes you don't login remotely as root

I fixed my own case of this error by removing id_rsa.pub from .ssh.

I had copied id_rsa from another machine and distributed it across several dummy clients. Therefore, id_rsa and id_rsa.pub were actually different keys which prevented the usage of id_rsa altogether.

No error message to clearly indicate this though. I figured it out essentially by accident, trying to get the different machines into an identical state.

From my finding, the least permission of the target's home director is 750. If the world's bit is not 0, it will not work.

Eg. for root's directory:

drwxr-x--- 3 root root 4096 Jul 20 11:57 root

Next is /root/.ssh

drwx------  2 root root  4096 Jul 17 03:28 .ssh

Then /root/.ssh/authorized_keys

-rw------- 1 root root 1179 Jul 17 03:28 authorized_keys

In my case the permissions on the home directory were 775 instead of 0755 or lower.

The entire path to authorized_keys file, i.e. /home/user/.ssh/ must be 0755 or lower.

After troubling a lot I got the solution of the problem:

Home directory of the user should not have permission 777 or world writable. If it is the case, SSH key verification will fail and you have to put password for login.