"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,
> --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.
>
> --require-key-and-password
>
> Not as flexible as the second idea, but easier to code.
>
> --require-key
> --require-password
>
> One option per auth mechanism.
>
> * Warning: you are now entering a floating-castles zone *
>
> 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
>
> could specify that the user can log in with key and password, or with just
> a one-time-password. Or some kind of syntax that would allow netmasks to
> be added, so you could specify that anything on the local net gets in with
> just a key or password, anything else requires both (which would be useful
> to me in the DMZ at my day job).
>
> --auth-control=net:12.9.219.0/24+*,(key+*)
>
> or
>
> --auth-control=(net:12.9.219.0/24,key)+*
>
> (assuming that * indicates a wildcard meaning any auth method not used
> in matching some other part of the condition. Meaning that net+key would
> be OK, since key wouldn't be used in the first part since you already have
> net, but net+net would fail.
>
> Thinking it might be easier to track down, or do, a noninteractive
> PAM-type setup.
>
> * You are now leaving the floating-castles zone, we hope no permanent
> damage was inflicted*
>
> > As for ssh-agent, the version I use with ssh1 uses a unix domain
> > socket located under /tmp/ssh-my-name/, which is protected using the
> > file system's permisison bits. Any ssh-agent like functionality for
> > lsh will probably use a similar method.
>
> And I realized that going farther than that is pointless on many OS, since
> many of them have a /proc structure that lets any process read the memory
> space of any other process that is owned by the same user, allowing any
> process that is running as me to peek into whatever program necessary
> to get the required password/passphrase.
