Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question
add comment

6 Answers

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

share|improve this answer
    
my .ssh is 700 and files in .ssh is 600, and I double checked ~/.ssh/authorized_keys in remote machine. Setup public key auth is the first thing I do after I install the system, so it's not likely to be messed up by other operation. btw, problem still.. –  lxyu Aug 23 '11 at 10:58
    
OK - I am adding something to my answer based on this. –  Linker3000 Aug 23 '11 at 11:55
    
there is a line of "#AuthorizedKeysFile %h/.ssh/authorized_keys". I tried comment it out, but of no use.. btw, the same '/usr/sbin/sshd' with the same 'sshd_config', how the they behave differently? –  lxyu Aug 23 '11 at 13:13
    
Finally I reinstalled ubuntu, then I set up openssh-server in one minute and it working fine now... Still don't know what's wrong. :( –  lxyu Aug 23 '11 at 17:24
    
Sometimes it is really difficult to find out what's the problem. I once mispelled authorized_keys as auhorized_keys. I needed about one hour to troubleshoot this. Did you see the mispelling? It is really tricky! :-) –  nalply Feb 24 '12 at 14:00
add comment

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.

share|improve this answer
add comment

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
share|improve this answer
add comment

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.

share|improve this answer
add comment

Just make sure the account you are trying to ssh to is a user with a password on the remote server. I just banged my head on the wall for half an hour before finding this answer here: http://stackoverflow.com/a/14421105/758174

share|improve this answer
add comment

After troulbing 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.

share|improve this answer
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.