Is it possible to avoid PAM calls for key based Auth methods

[Nicolas Williams]

On Tue, Feb 15 2005 at 16:56:35, Darren Tucker wrote:
> Potentially, sshd could do a couple of things to the auth type to PAM so 
> it could behave differently:
> 
> - sshd could set a PAM environment variable containing the authentication 
> type.  (Although PAM's configuration syntax is pretty limited.  You could 
> have a "sufficient" module early in the stack that returns immediately if 
> that variable is set to, eg "public-key").

You really don't want to do this as this means making modules aware of
ssh protocol specific details just so you can configure each ssh
authentication method differently.

> - sshd could use different PAM service names for the different auth types. 
>   (eg "sshd-public-key", "sshd-password", "sshd-gssapi-with-mic" and fall 
> back to "sshd" if these don't exists.  This would probably be tricky to 
> write because you'd have to stop and start PAM for each auth attempt.)

Solaris 10's sshd does this.  See:

http://docs.sun.com/app/docs/doc/816-5166/6mbb1kqh7?a=view#indexterm-768

The service names it uses are:

 - sshd-none
 - sshd-password 
 - sshd-kbdint
 - sshd-pubkey
 - sshd-hostbased
 - sshd-gssapi (for both, gssapi-keyex and gssapi-with-mic)

You might want to use those too...

[Note that you can't expect the PAM configuration to be re-read when
setting the PAM_SERVICE item, so you have to pam_start() a new handle
for each service.  On Solaris 10 pam_set_item() returns an error
(PAM_PERM_DENIED) if the application attemps to set the PAM_SERVICE
item.]

> > I mean PAM calls should not be called for key based Auth methods, 
> 
> I disagree with that for the general case: there's many valid reasons to 
> call the non-auth PAM functions for non-password auths (eg account expiry, 
> session modules).

Exactly.  What he said.

Nico
--