SSH Protocol 2 provides a public-key-based user (PubkeyAuthentication) or client host (HostbasedAuthentication) authentication method, conventional password authentication and challenge response based methods.
The entry HostbasedAuthentication in sshd_config specifies whether rhosts or /etc/hosts.equiv authentication together with successful public key client host authentication is allowed.
The entry IgnoreRhosts in sshd_config specifies that .rhosts and .shosts will not be used in HostbasedAuthentication — /etc/hosts.equiv and /etc/ssh/shosts.equiv are still used.
Host-based and r/shost-based authentication offers low-level security — don't use it!
Traditional /etc/passwd//etc/shadow authentication can be implemented by the PasswordAuthentication flag in sshd_config. While the authentication protocol is no more secure than that for telnet or FTP (clear text passwords), the network connection is encrypted, so password "sniffing" is make difficult.
(This is equivalent to using challenge-reponse (keyboard-interactive) authentication with PAM and specifiying the pam_unix.so module.)
In this case he server sends an arbitrary "challenge" (text) and prompts for a response — there may be multiple challenges and corresponding required responses. Cchallenge-response authentication examples include BSD Authentication (see login.conf(5)) and PAM.
Use this method if using PAM-based LDAP authentication.
Required entries in sshd_config:
ChallengeResponseAuthentication yes UsePAM yes Protocol 2
Required entries in ssh_config:
ChallengeResponseAuthentication yes PreferredAuthentications keyboard-interactive Protocol 2
N.B. Unless OpenSSH has been compiled with --with-pam set UsePAM will have no effect — there will be no error message.
By far the best (most secure) authentication method to use is key/passphrase authentication — here a public/private key-pair is used (DSA or RSA), with the private key encrypted by a passphrase (blank characters are allowed).
Blank passphrases are permitted — useful, for example, if a cron job needs to authenticate to another host. In such cases the server-side host should limit the access the client has, by using a restricted-shell such as rssh or making use of the command= feature in the authorized_keys file.
For (much) more on publickey authentication see below.
OpenSSH can also work with Kerberos, but that is beyond the scope of these pages.
...previous | up (conts) | next... |