[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: How to write a client/server conversation function

Chris Albertson writes:
> My question is how to write a converstion function.  The
> documentation in /usr/doc and in the rfc is sparce. I
> can't simply use a printf() fro the prompt and fgets to
> read the password.  What does a converstion function do
> in the case of a client/server setup?  The client program
> needs to be able to run in a batch mode.  from a script
> of maybe from the crontab.  Prompting is out.  I am not
> really sure what a converstion function must do.
> Is there any way to avoid storing/transmitting the pasword
> in the clear?
> What should I be readng to learn more? 

I am doing something similar for internal use here at Transmeta.  One
of the things that the original PAM spec failed to address is the
issue of non-interactive authentication...  The last major additions
to PAM are things that should be of interest to you, and your
experiences/feedback/help would be much appreciated for improving the
solution that is under development.

The solution is "binary" prompts and support for client-side
modularity...  This is the libpam_client stuff in the more recent pam
tar balls.  The idea being that if you add a batch mode of
authentication to your server, you can plug in the corresponding
support to your client...

The other thing that may be relevant to you is the multi-threading
support that is starting to solidify, although, if your server fork()s
a process for each incoming connection this is not likely to be a
concern. [Mine doesn't so I'll finally have a test case with which to
iron out this corner of the library...]

As to whether there is a way to avoid storing/transmitting the pasword
in the clear?  The answer is yes.  Shared secrets can be made
cryptographically strong at the expense/risk of storing a
shared-secret on both the server and the client... There is an example
server(module)+client(agent) of this in the libpam_client code
(courtesy of Andrey).  A more secure solution would be to use
asymmetric cyphers, but this is "too strong" for me to think about
putting code for in the publically available PAM tar ball ;)  Is there
anyone in the freer-world that would be willing to develop such an

So, the tecnology for what you want to do is mostly available. The
question is do you want to pour over the source and work out what you
need before I get the time to document it more fully?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []