SecurID

[Dan Kaminsky]

> >     Any objection to a "Userspace PAM", i.e. a password authenticating
> > equivalent to ProxyCommand for proxy tunneling?  I'd probably name it
> > AuthCommand.
>
> I don't understand what you are proposing.

AuthCommand "/usr/bin/secureid_check secureid.company.com $username
$password"

$ /usr/sbin/secureid_check
Usage: /usr/sbin/secureid_check host username password
    Returns(or echos ACCEPTED) 0 if connection accepted.
    Returns(or echos REJECTED: #) 1-255 for various reasons of
rejection(this is for flexibility with other apps).
    Echos maxlength string for insertion in a packet_send_debug("%s",
message) call.

This way, the *entire* process of any non-negotiating authentication API can
be encapsulated away, much in the manner ProxyCommands have been.  Oddly
enough, this would actually work *much* more smoothly than ProxyCommands,
since it modifies a permanent server configuration instead of a temporary
client configuration.

The security concern, of course, is that command line arguments generally
leak into the process tree.  There are ways to solve this--from accepting
arguments on stdin to OS-dependant argv quashing--but I'm open to ideas.

Functionality is obviously limited--particularly in terms of
challenge-response--but would really allow SSH to much more elegantly
support far, far more external authentication systems with very little
effort.

See http://www.itlab.musc.edu/~nafees/mod_auth_any.html for the equivalent
in Apache.

I'll probably hack out a beta this weekend and see if it's anywhere near as
elegant as it sounds.  It's a general purpose solution to a cluster of
specific problems--and it's blissfully userspace.  What more could a guy
want?

Yours Truly,

    Dan Kaminsky, CISSP
    http://www.doxpara.com