control of auth methods

[Jefferson Ogata]

Damien Miller wrote:
> Jefferson Ogata wrote:
>>I thank what would work would be to make the sshd_config syntax consistent with 
>>the ~/.ssh/config syntax, but instead of Host sections, have User sections. In 
>>addition, instead of AllowUsers/DenyUsers you could use Allow/Deny keywords or 
>>something similar. We should also allow specification of sub-auth-types. 
> 
> 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.

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

And the more I dig through the code the more I see what a morass the whole thing 
is. Try following the server loop for versions 1 and 2 respectively, through 
session.c, serverloop.c, back again to session.c.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>