control of auth methods

Damien Miller djm at mindrot.org
Sat May 8 15:02:57 EST 2004


Jefferson Ogata wrote:
>>I don't think we are interested in adding complex policy enforcement
>>to the server. If we did this, we would be more likely to reuse an
>>existing policy language such as KeyNote. I had patches for this a
>>couple of years ago - check the archives.
> 
> That must be the royal "we", because it certainly doesn't include me. As for 
> "complex policy enforcement", that's more like what we have now. I'm just 
> talking about trying to be explicit about it.

Well, that's the good thing about OpenSSH being free software. What I
like doesn't in any way restrict what you can do.

BTW I say "we" because Markus has decided against this level of
complexity before and I defer to his good judgement even when I
disagree (which I don't here).

> The current design of the config file is hardly a triumph of simplicity and 
> logic. The auth types have internal names, yet the auth controls are this morass 
> of booleans. It would make more sense to list the internal names, a la Ciphers. 

Except you weren't talking about tidying up the authentication method
names, you were talking about effectively introducing a policy language.

Perhaps we would be willing to add a single "AuthMethods xxx,yyy,zzz",
where xxx, etc are the auth method names used in the protocol. We'd have
to keep the older names around for a fair while to stop breakage.

> Instead we have to figure out how various combinations of peculiarly named flags 
> such as PAMAuthenticationViaKbdInt, PermitRootLogin, 
> ChallengeResponseAuthentication, RhostsRSAAuthentication, UsePam, AllowUsers, 
> DenyUsers, etc. interact to produce which set of valid auth types for whom. It 
> ends up being trial-and-error to determine whether the right users can 
> authenticate the way you want to allow, and /can't/ authenticate the way you 
> want to prevent, and that's not a good design for security.

I think you are overstating this. There is some confusion about the
effect of UsePAM=yes, but the others are quite clear. PAM is something
of a special (basket?) case anyway, because there one is delegating
control to PAM's policy.

-d




More information about the openssh-unix-dev mailing list