Argh! I sent the previous reply to fast (pressing C-c C-c instead of
C-x C-x). A new try:
"Eric J. Schwertfeger" <[EMAIL PROTECTED]> writes:
> On 18 Apr 2000, Niels M�ller wrote:
>
> > What should the user interface for that (i.e. lshd command line flags)
> > look like?
>
> I don't know the internal mechanics of lshd, so I don't know which of the
> following would fit the best. It largely depends on what mechanism would
> be used for adding additional auth mechanisms in the future.
>
> --require-authcount=2
>
> specifies that the user must auth using two methods rather than just one,
> though this doesn't control what two methods can be used.
I'm not sure this is terribly useful. It also seems a little
dangerous, in that the meaning of --require-authcount=2 changes if you
uppgrade lshd to a version that implements yet another userauth
method.
Hmm, let me explain how the userauth protocol works... SSH
userauthentication is a series of requests and responses, where each
request consists of
* username,
* requested service,
* method,
* some evidense (signature, password, etc)>
The client can send any requests, and use any username or meathod in
each request.
For each request, the server has to tell the client if it was a
success or a failure, and a suggestion about which methods the client
might want to use next.
The server would keep a state machine where the transitions are (i)
successful userauth requests and (ii) a transition back to the
startstate each time the client uses a new user name or service.
> --require-auth=key,password
>
> Allows for explicit control of whatever auth methods are added in the
> future. Maybe allow for =key,* for key and any one other auth mechanism.
Makes sense, I think.
> --require-key-and-password
>
> Not as flexible as the second idea, but easier to code.
If we go this way, perhaps it is better with
--userauth-policy key-and-password
> --require-key
> --require-password
>
> One option per auth mechanism.
This adds a "required"-bit to each userauth method. It is probably the
easiest to implement (the state consists of one bit for each required
method), and it should also be easy to understand.
> Hmmm.... thinking about the way Apache allows you to layer authentication
> schemes. Of course, the parsing gets more complicated at that level.
> Maybe something that allows and/or type logic. Use , for or, and + for
> and, and allow parenthesis.
>
> --auth-control=(key+password),otp
I was actually thinking of something like that, even if I find it
strange to use + and , as operators.
I'd a grammar like
<atom>: "password", "publickey" or "otp", a single method
<atom>: "*", any method not already satisfied
<expr>: <expr> "|" <expr> (alternatives)
<expr>: <expr> "&" <expr> (require both)
<expr>: "(" <expr> ")"
with some precedence reules to handle "foo | bar & baz".
I suspect this is quite tricky to implement properly, analyzing the
expression to build a state machine is somewhat similar to compiling a
regular expression.
> --auth-control=net:12.9.219.0/24+*,(key+*)
I don't think I'll give tcpwrapper-like access control a high
priority. Perhaps it's easier to link with the tcpwrapper library, but
I haven't really looked at that.
/Niels
