Re: using one time passwords with conserver?

On Sun, Jul 23, 2006 at 09:03:34AM -0700, Bryan Stansell wrote:
> hmm...well, that's kinda tricky.  the issue is that there are multiple
> conserver process that the client talks to (the master, then the actual
> one managing the console - in the simplest form).  the client actually
> caches the password so that it can re-authenticate with the extra
> processes without harassing the user.  in your case, you should be
> getting multiple password requests, right?  you'd authenticate with the
> first, conserver would try and re-use the password with the second,
> fail, and then ask for the current password.

yep, exactly.

> removing the need for multiple passwords *might* be possible.  i could
> see removing the need for authenticating against the master
> process...just have it skip password stuff (which means removing a few
> lines of code) and let the user authenticate once against the process
> managing the console.  this would allow folks to gather data...so not
> something i'd do for the general release (well, maybe as an option), but
> you may not like that either.

What sort of data could they gather?

> another possibility is to setup a "console" host that does nothing but
> allow folks to access conserver (it could even be the same box).  when a
> user logs in, instead of a shell, you get a console command that
> attaches to some pre-determined console.  how does this help?  well, you
> turn off all authentication in conserver and can assume that anyone
> attaching has already authenticated with the host, so they should be who
> they say they are.  and, actually, you could create a "noop" console
> that they all fall into by default, and then they just need to use
> "^ec;" to switch to another console.  kinda different, but doable, in my
> opinion.  it's not a 100% solution, but it's close (in addition i'd say
> they should all be "limited" users (in conserver.cf terms), but then you
> wouldn't be able to switch consoles).

This is kinda what we have going currently, but it's not ideal.  People
other than our admin staff have access to the conserver host.  Some of
the admins would also like to not have to log in to that host and
instead use the conserver client from their desktop.