After a longer than desired struggle with getting sshd to accept my public key, I think a blog post is in order to remind myself not to repeat the same mistakes. Here’s how you should go about debugging your SSH public key authentication woes:
Getting more debug info when connecting with your ssh client: Add a ‘-v’ option to your ssh command (e.g. ssh chuyeow@remotehost -v -v -v). Add more ‘-v’ for more detailed debug (you can do up to ‘-v -v -v’ I think).
Debugging on the remote host by running sshd in debug mode: Run ‘/usr/sbin/sshd -d -p 2222′ on the remote host and connect to it. ’2222′ here is the port number of the sshd process you started on the remote host.
tail the authentication log: Run ‘tail -f /var/log/auth.log’ on the remotehost. You can watch the log as you try to connect via SSH with your key.
Make sure your ssh key agent is running: Do a ‘ps aux|grep ssh-agent’. Make sure your key agent is running. If you’re not using ssh-agent (I like keychain from Gentoo, or SSHKeyChain for Mac OS X), do whatever you have to do to ensure that your keychain is running.
Make sure your private key is added to the ssh key agent: Do a ‘ssh-add -l’ to check that ssh-agent has your key. Likewise, if you are using something else, check your keychain application has your private key.
Check the permissions on your home directory, .ssh directory, and the authorized_keys file: If your ssh server is running with ‘StrictModes on’, it will refuse to use your public keys in the ~/.ssh/authorized_keys file. Your home directory should be writable only by you, ~/.ssh should be 700, and authorized_keys should be 600.
Tailing the authentication log was the clincher for me this time – my problem was the group permissions on the home folder were incorrectly set (the error message I got from auth.log was: ‘Authentication refused: bad ownership or modes for directory /home/chuyeow’). Just had to fix it so it was no longer group-writable. Of course, this can also be fixed by turning setting ‘StrictModes off’ in your sshd config (/etc/ssh/sshd_config), but it’s not really recommended. Plus, you may not always have the rights to edit that file anyway.