SSH Authentication Options for Public Keys
Written by Dave Bandel on 25-July-02.

Depends on whether you're talking about protocol 1 or 2.  They are different.  However, both have similar way to authenticate a
system:
 
password login  (what you don't want)
rhosts login (a bad idea)
authorized keys (what you want)
rhosts + authorized keys (more restrictive than what you want, but may stop an authorized host because you can't establish identity)
user logins (more restrictive, but may work as well)
 
Protocol 1:
RhostsAuthentication: (uses the rhosts file -- a _real_ bad idea)
RhostsRSAAuthentication:  leave as no
RSAAuthentication:  what you want for a protocol 1 client.
 
Protocol 2:
HostbasedAuthentication:  you don't want this (default no), same as RhostsAuthentication above (uses hosts.equiv vice rhosts)
PubKeyAuthentication -- WHAT YOU WANT! Default = yes.
 
Both Protocols:
AllowUsers  takes a list of space separated usernames (or user@host) and only allows these logins -- might work for you in addition to PubKeyAuthentication (above).
IgnoreRhosts -- a good idea
IgnoreUserKnownHosts -- a _really_ good idea if you want to control which hosts can log in.
PAMAuthenticationViaKdbInt -- leave as no.
KerberosOrLocalPassword -- make this no.  Will use Kerberos or fall back to /etc/passwd.
PasswordAuthentication -- set this to no.
PermitEmptyPasswords -- really bad idea (no one should have a null password).
PermitRootLogin -- leave this as yes.
UseLogin -- leave as no (you definitely don't want this).   

I suggest you restrict logins to protocol 2 if at all possible.  Just specify:
Protocol 2  
searchSearch Index