Why won't automatic login through ssh with authorized_keys work?
Solution 1:
The server will ignore your authorized_keys file if the owner properties are wrong. Changing it to this fixes it:
chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys
Solution 2:
Although your problem may have already been solved by other answeres, I've locked myself out of enough machines from not validating sshd_config changes before signing off so have come up with the below process that might be useful for future debugging of sshd config changes:
DO NOT DISCONNECT an active ssh connection until AFTER testing has verified behaviour is as you expect.
a. verify what you think sshd is supposed to be doing
b. verify the configuration is valid using "-t"
c. start a verbose 'test' version of the server you can live monitor
d. start a verbose 'test' client connection you can live monitor
a. verify what you think sshd is supposed to be doing
Review the sshd configuration file without all the commentary with something like the below (assuming sshd_config is the correct file and in /etc/ssh)
$ grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"
This just clears things out so we verify what we think we're changing (not necessarily whether it is correct or not.)
b. verify the configuration is valid using "-t"
From the man page of the sshd's I'm using,
-t Test mode. Only check the validity of the configuration file and sanity of the keys. This is useful for updating sshd reliably as configuration options may change.
Other changes can have more subtle circumstances. For example, do not disable password authentication until you are sure that the public key authentication is working correctly.
c. start a verbose 'test' version of the server you can live monitor
$ sudo /usr/sbin/sshd -ddd -p 9999
This keeps your existing, working session active, but gives you another instance of sshd to verify your new configuration changes. SSHD is now running in the foreground to a user-defined port (9999 in our example.) and pushing a lot of noisy debug information you can track in /var/log/authlog (or possibly /var/log/auth.log depending on your OS.)
d. start a verbose 'test' client connection you can live monitor
Run the ssh client connection in verbose mode to display on your screen more information that might lead you to better debugging your error.
$ ssh -vvv -p 9999 server-name
You should now have enough information in either the server's log files, or the client's connection screen to isolate your problem.
The solution generally comes down to file permissions (as shown by Magnar and setatakahashi)
Best of luck
Solution 3:
$ chmod 700 ~
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys
Check for these attributes in /etc/ssh/sshd_config
$ sudo grep PubkeyAuthentication /etc/ssh/sshd_config
$ sudo grep Protocol /etc/ssh/sshd_config