PAM & Configure

[Smith, Donald]

Damien having said that PAM is an unmanagable pain what is the 
objection to haveing Theo Schlossnagle's securid patch included into the cvs
tree?

The pam+kbdinteractive is not a solution if you have to support older ssh
clients (protocal 1).

Donald.Smith at qwest.com IP Engineering Security
303-226-9939/0688 Office/Fax
720-320-1537 cell

> -----Original Message-----
> From: Damien Miller [mailto:djm at mindrot.org]
> Sent: Tuesday, January 16, 2001 6:07 PM
> To: Darren J Moffat
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: PAM & Configure
> 
> 
> On Tue, 16 Jan 2001, Darren J Moffat wrote:
> 
> > Damien Miller wrote:
> > > The change was made because there is no workable way to 
> make PAM work
> > > 'out of the box'. Each vendor implements PAM a little 
> differently and
> > > there appears to be no standard on the naming of modules 
> or the augments
> > > they take.
> > 
> > Just a point to note here; SSHD as an application should NOT be
> > dependant on any module existing. Applications should not assume
> > anything about what modules are available since this breaks 
> the entire
> > concept of what PAM is all about. If this is the reason why PAM is
> > being disabled then there are wrong assumptions in SSHD 
> about what PAM
> > should be doing and those should be fixed.
> 
> sshd doesn't, but how are you supposed to install a default 
> configuration file if there is not set of standard modules with
> standard arguments?
> 
> > Could you give a summary of what problems there were with the PAM
> > framework being different on platforms specifically how that relates
> > to OpenSSH ?
> 
> There is no way to cleanly install a default config across the various
> versions of PAM. Different implementations use different modules with
> different arguments (even pam_unix.so can't be trusted to 
> have the same
> args between different Linux distributions).
> 
> The PAM API is annoying in that it has been (presumably) 
> crafted to fit
> the needs of login or telnet. i.e get a bit of information at a time, 
> return textual prompts and then get the next bit. We have to resort to
> kludges (the conversation function which assumes ECHO_OFF prompts are
> asking for passwords) to get the username and password into 
> PAM in the 
> first place.
> 
> The SSH2 KbdInteractive auth mode is a better match to the PAM way of 
> doing things, but it would be nice if PAM had more flexability in its
> API.
> 
> My other gripe about PAM (unrelated to ssh) is that it 
> doesn't seperate
> mechanism and policy. Specifying .so files with magic options 
> is just too
> fragile.
> 
> > FYI PAM was proposed to X/Open as a draft standard but never got
> > completed, 
> > AFAIK Linux and Solaris are similar in most respects for PAM.
> > Solaris implements what was in the standard but Linux went off and
> > "embraced
> > and extended (with source available)" and made enhancements 
> and changes
> > to this.
> 
> Has there been any movement towards reworking the standard?
> 
> -d
> 
> -- 
> | ``We've all heard that a million monkeys banging on | 
> Damien Miller -
> | a million typewriters will eventually reproduce the | 
> <djm at mindrot.org>
> | works of Shakespeare. Now, thanks to the Internet, / 
> | we know this is not true.'' - Robert Wilensky UCB / 
http://www.mindrot.org