openssh vs pam

[Nicolas Williams]

On Sat, Jun 25, 2005 at 11:38:46PM +1000, Darren Tucker wrote:
> >Disagree. It is quite possible for ssh v2 to work properly with PAM.
> >I have it working. Sun has it working.
> 
> I specified SSHv1 and SSHv2, but sticking to just SSHv2, could you 
> please explain how you do the following within the existing SSHv2 
> protocol and PAM interfaces:
> 
> a) Perform the "none" auth test specified by SSHv2 via PAM without 
> causing either unnecessary delays or spurious failure messages from PAM 
> in the logs.  Currently sshd doesn't try PAM for "none" if 
> PermitEmptyPasswords=no but strictly speaking that's a hack.

Solaris 10's sshd uses a different PAM handle and PAM_SERVICE for each
SSHv2 userauth.  This allows sysadmins to configure the "sshd-none"
service to only have, say, pam_deny.so.1 in its stack.  This lets you
avoid the delays and spurious failure log entries (and failure counting
towards account locking).

> b) Perform vanilla "password" USERAUTH_REQUEST via PAM in a way that 
> works for the general case.

General case?  As in when a PAM module wants to prompt for something
other than PAM_AUTHTOK?  Can't be done.  That's why we have
"keyboard-interactive" userauth.

> Now a) you can configure around, and I imagine your response to b) will 
> be "use kbdint, that's what it's for!" :-)

Indeed.  Every client I've used in recent memory supports it.

> My point is there are parts of the spec that you can't implement 
> perfectly via PAM, given the current protocol and PAM implementations. 

"keyboard-interactive" works fine.

Conversations during other userauths are more troublesome; as long as
they are text info messages they can just be saved for display later on
a tty channel.  Not that I can think of any PAM modules that converse
prompts during pam_open_session(), or pam_setcred(), or pam_acct_mgmt().

Password aging should trigger userauth failure, for userauths other than
"keyboard-interactive," with kbd-int being the only userauth that can
continue.

> It's not that OpenSSH can't improve (I've already said that it can).

Again, "keyboad-interactive" interfaces with PAM just fine.

> Originally I had another thing in the list, which I now think is 
> possible but tricky, and wanted to know if you implemented it and if so, 
> how:
> 
> c) Handle the case where pam_acct_mgmt() wants to interact after a 
> public-key authentication.

See above.  Prompts can't be handled in that case.  But, by using
"sshd-pubkey" as the PAM_SERVICE you give the sysadmin a chance to
configure PAM so that this doesn't happen during pubkey userauth.


> A separate but related issue to the fact this complex interface is 
> supplied via a callback.  It's the callback that's the primary problem 
> in sshd's case, though.  Give me a reentrant equivalent to the 
> conversation function and I can live with the rest.  It could probably 
> even fit withing the existing API with a few new flags.

So, shall I repeat myself and point out a good way to handle this?

> >This is a great example of both not understanding PAM and not wanting
> >to. One, you're wrong, two, you can't imagine that the PAM interface
> >might be the way it is for a reason, rather you insist that it's
> >broken and refuse to accommodate it.
> 
> You seem to be confusing understanding it with having a high opinion of 
> it.  Do you believe that PAM is so fundamentally clean, elegant and 
> beautiful that if someone understood it they could not fail to like it?

Does it matter?  Do you want to support it or don't you?  What you
dislike about it the most cannot be fixed.

> >The Sun patches are readily available.
> 
> Really?  Where?  If you're referring to OpenSolaris the when I looked, 
> ssh was one of the components that is not part of the release.  (Nico: 
> any particular reason for this, and is it expected to change?)

Ssh will be there soonish.  That it isn't there now is kinda my fault;
details next week :)

> For the SSHv2/kbdint case I guess it could pass the messages through to 
> the client directly rather than accumulating which should be an 
> improvement, right?

Yes.

> >I think there's something specifically wrong with privsep and PAM but
> >I'll be damned if I can think of it now. (I've never used privsep
> >because it was historically broken for PAM, nowadays some issues are
> >fixed but there's no privsep value for me.)
> 
> I'll stipulate that privsep makes dealing with PAM harder.

I don't think it does -- the monitor has to nest its event loop, and
this is no harder in the monitor than in the non-privsep case.

> Anyway, I do appreciate your time (and Nico's) even when I'm not 
> agreeing with you.

Cool.

Nico
--