2. Authentication Methods

SSH Protocol 2 provides a public-key-based user (PubkeyAuthentication) or client host (HostbasedAuthentication) authentication method, conventional password authentication and challenge response based methods.

2.1. Host-Based and R/Shost-Based Authentication — don't use!

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!

2.2. Traditional Password

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.)

2.3. Challenge-Response (Keyboard Interactive)

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.

2.4. Publickey — with Passphrase

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.

2.5. Kerberos

OpenSSH can also work with Kerberos, but that is beyond the scope of these pages.

...previousup (conts)next...



About this document:

Produced from the SGML: /home/mc/public_html/_ssh/_reml_grp/ssh.reml
On: 4/4/2006 at 17:51:25
Options: reml2 -i noindex -l long -o html -p multiple