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
Search
