Howto fix this: ssh daemon asks for a password

今天折腾Git的升级，一下子把gitolite和gitlab都升级到了最新的。也遇到了不少问题，其中一个比较头疼的就是还和gitolite和gitlab都没有关系，是ssh的问题，后来在gitolite的文档中找到了很详细的处理办法，摘录在此。

appendix 1: ssh daemon asks for a password

NOTE: This section should be useful to anyone trying to get password-less access working. It is not necessarily specific to gitolite, so keep that in mind if the wording feels a little more general than you were expecting.

You have generated a keypair on your workstation (ssh-keygen) and copied the public part of it (~/.ssh/id_rsa.pub, by default) to the server.

On the server you have appended this file to ~/.ssh/authorized_keys. Or you ran something, like the gitolite setupstep during a gitolite install, which should have done that for you.

You now expect to log in without having to type in a password, but when you try, you are being asked for a password.

This is a quick checklist:

• Make sure you’re being asked for a password and not a passphrase. Do not confuse or mistake a prompt saying Enter passphrase for key '/home/sitaram/.ssh/id_rsa': for a password prompt from the remote server!

  When you create an ssh keypair using ssh-keygen, you have the option of protecting it with a passphrase. When you subsequently use that keypair to access a remote host, your local ssh client needs to unlock the corresponding private key, and ssh will probably ask for the passphrase you set when you created the keypair.

  You have two choices to avoid this prompt every time you try to use the private key. The first is to create keypairswithout a passphrase (just hit enter when prompted for one). Be sure to add a passphrase later, once everything is working, using ssh-keygen -p.

  The second is to use ssh-agent (or keychain, which in turn uses ssh-agent) or something like that to manage your keys. Other than discussing one more potential trouble-spot with ssh-agent (see below), further discussion of ssh-agent/keychain is out of scope of this document.

• Ssh is very sensitive to permissions. An extremely conservative setup is given below, but be sure to do this on both the client and the server:

  cd $HOME chmod go-rwx . chmod -R go-rwx .ssh 

• Actually, every component of the path to ~/.ssh/authorized_keys all the way upto the root directory must be at leastchmod go-w. So be sure to check / and /home also.
• While you’re doing this, make sure the owner and group info for each of these components are correct. ls -ald ~ ~/.ssh ~/.ssh/authorized_keys will tell you what they are.
• You may also want to check /etc/ssh/sshd_config to see if the “git” user is allowed to login at all. For example, if that file contains an AllowUsers config entry, then only users mentioned in that line are allowed to log in!
• While you’re in there, check that file does NOT have a setting for AuthorizedKeysFile. See man sshd_config for details. This setting is a show stopper for gitolite to use ssh.
• Some OSs/distributions require that the “git” user should have a password and/or not be a locked account. You may want to check that as well.
• If your server is running SELinux, and you install gitolite to /var/gitolite or another location unsupported by default SELinux policies, then SELinux will prevent sshd from reading .ssh/authorized_keys. Consider installing gitolite to/var/lib/gitolite, which is a supported location by default SELinux policies.
• If all that fails, log onto the server as root, cd /var/log, and look for a file called auth.log or secure or some such name. Look inside this file for messages matching the approximate time of your last attempt to login, to see if they tell you what is the problem.