Tero Kivinen wrote:
> 
> Andrew Morgan writes:
> > The non-tty input methods we implemented were via a single 'BINARY'
> > message type.
> 
> What authentication methods there are that use those BINARY messages?
> I am not talking about what might be, I am talking about what
> currently exists?

We have a publicly available simple shared secret authentication that is
basically a proof of concept thing (its in the Linux PAM sources). I
have also prototyped code that will do RSA. If you discount 'what might
be', however, then you really are missing the point of PAM.

> So this seems to be same thing that the ssh-agent does?

It has some similarities. The agent as we have defined it is really a
client side PAM module. Its the complement to a PAM module that is
plugged into the server. Because of the way we've constructed things,
this agent can be a simple perl (or even Java) program, or (for machine
to machine private authentication where the client need/should not know
the details) an execute only binary.

This PAM-agent is only for authentication, and is of course designed for
use by other client/servers besides SSH.. It could be used with (a
slightly modified) telnet or some other client/server. To paraphrase
Mike Eisler, the point is that a server application needs to lend its
transport layer to PAM for the duration of the authentication process.
SSH stands out as desirable because it provides an encrypted transport
layer, but with BINARY message types there is nothing to prevent the
PAM-module/agent combo from encrypting their own authentication
exchange.

PAM aims to provide generic and pluggable support to applications for
locally provided/configured authentication methods -- but nothing more.
Perhaps I am mistaken, but I understood that ssh-agents are also used
for tunneling different transport protocols (X, ppp...) over an SSH
connection? PAM is well out of the picture for this sort of thing (and
with the ssh-1.2.* patch we wrote well over a year ago), does not
interfere with this useful SSH-specific feature.

Cheers

Andrew

Reply via email to