On 18 Apr 2000, Niels M�ller wrote:
> "Eric J. Schwertfeger" <[EMAIL PROTECTED]> writes:
>
> > As an interrum measure before we have passphrase-protected keys, how hard
> > would it be to set lshd to require both an authorized key, and a password?
>
> Hmm. think the client can do that already. And the protocol os
> obviously designed to support that. What is needed is a little more
> flexibility and logic on the server side.
>
> 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.
--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.
