sshd_config for ssh without password (using a public key)

It seemed so easy to get ssh working without providing a password (using a public key)...

On you client just execute (password left empty):

ssh-keygen -t dsa

Copy the created id_dsa.pub file to the server:

scp ~/.ssh/id_dsa.pub myuser@222.222.222.222:~/.ssh/authorized_keys
scp ~/.ssh/id_dsa.pub myuser@222.222.222.222:~/.ssh/authorized_keys2
scp ~/.ssh/id_dsa.pub myuser@222.222.222.222:~/.ssh/id_dsa.pub

Then ssh to the server without using your normal password. Well for me that just did not work! The last three days I have been googling arround for help on the problem and at last I found the solution. It seems like the problem is common but the reasons varies. One of the major errors are permissions on directories. My problem was not related to permissions but to the sshd_config file on the server. As I couldn't find anyone posting a working configuration file here it goes:

/etc/ssh/sshd_config:
# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication yes
# similar for protocol version 2
HostbasedAuthentication yes
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords yes

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM no

AllowTcpForwarding yes

AuthorizedKeysFile /usr/NX/home/nx/.ssh/authorized_keys2

This is the content of ~/.ssh directory on the client:
-rw------- 1 username staff 668 26 Okt 22:08 id_dsa
-rw-r--r-- 1 username staff 635 26 Okt 22:08 id_dsa.pub
-rw------- 1 username staff 786 22 Aug 19:27 known_hosts

This is the permisions of ~/.ssh directory on the server:
drwx------ 5 username staff 170 26 Okt 22:08 .ssh

This is the content of ~/.ssh directory on the server:
-rw------- 1 username username 635 Oct 26 22:09 authorized_keys
-rw------- 1 username username 635 Oct 26 22:09 authorized_keys2
-rw------- 1 username username 635 Oct 26 22:09 id_dsa.pub
-rw------- 1 username username 1326 Oct 26 02:05 known_hosts

This is the permisions of ~/.ssh directory on the server:
drwx------ 2 username username 4096 Oct 26 22:09 .ssh

This is the permisions of the user directory (~) on the server:
drwxr-x--- 4 username username 4096 Nov 2 18:40 username

If this does not work you can change the log level in /etc/ssh/sshd_config:
LogLevel DEBUG3

Restart sshd:
sudo /etc/init.d/ssh restart

And watch the log while you try and log in:
tail -f /var/log/auth.log

By the way. I'm runing Ubuntu 8.04 on the server and OSX Leopard on the client. See also http://www.securityfocus.com/infocus/1810