On 18 Apr 2000, Niels M�ller wrote:
> Argh! I sent the previous reply to fast (pressing C-c C-c instead of
> C-x C-x). A new try:
Thought so, done that myself. Never seem to log into the mail relay fast
enough to kill it there, either :-)
> > --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.
Agreed. I didn't like it much either.
> > --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
No perhaps, I definitely like this better, as it is expandable.
> > --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.
The only downside to this as opposed to --userauth-policy is that
--userauth-policy might be able to specify a configuration where
two-out-of-three is good enough. I don't see that as an issue, and in
combination with my realization at the end of this email, consider this
solution acceptable (not the best, but the best practical solution).
> > 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.
Was using them because they don't have to be quoted, but that's a very
minor issue. Not like we're tying this in every time we start lsh, just
lshd, and that is probably in a script.
> 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".
Looks good to me,
> 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.
All too true, and not very beneficial until more auth types are created.
Maybe I'll prototype something to parse this in the future, but it isn't
needed yet.
> > --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.
Agreed, it shouldn't be high priority. I'm not sure tcpwrappers would do
what I want, anyway, as I want some way to communicate back to lshd that
it's coming from a semi-trusted network, so the password isn't necessary.
The goal is to set up a way so that lsh commands from the semi-trusted
network/host can use publickey auth to execute commands from machines
behind the inner firewall, but to do anything from my home machine
(reasonably secure, but up 24x7, only self-firewalled, and running
sendmail and apache) require a password in addition to publickey auth.
That way, if security on my home machine is compromised, this doesn't
compromise security within the DMZ until they snoop my password.
Hmm... not the solution for everyone, but I can certainly run two
invocations of lshd; one that requires both on the normal port, and one
aht requires only publickey authentication on a different port, and then
block that port at the outer firewall. Most of the time that I need
something run without a password, it will be from a script anyway, so
specifying a port won't be a major issue.
