pam_sshauth update - status update, ready for hacking?

Hello all;

So, a couple of people have been emailing me with questions about smart cards,
and I had some thoughts in the last couple of weeks about minimizing the amout
of C code in pam_sshauth to make it easier on us all to modify and adapt the
bits I write, so after a frantic few days of late-night hacking, here's the
results:

https://code.launchpad.net/~sbalneav/ltsp/libpam-sshauth

The README file with the package should be fairly up to date.

In short:

I've extrapolated out the "launching of the ssh tunnel" into a shell script.
We are finally, FINALLY done with reading and/or writing to ssh interactively,
and using SSH_ASKPASS to provide ssh with it's password needs; I've written a
small and simple ASKPASS helper that uses POSIX shared memory to actually
temporarily store and retrieve the password.

What this means is that spawning the tunnel itself is now down to ONE line of
code; err, well, 3, since I split it up over 3 lines for clarity; check the
"examples/ltsp-session" script included for details; I think you'll ALL be very
VERY pleased with how simple it is under this scheme to launch the tunnel.  We
even launch with the -N (don't execute a remote command) option.  No more
"LTSPROCKS" sentinel.  I want to laugh AND cry at the same time.

So, here's what I think needs to be done to "proof of concept" this:

1) Pick a display manager we'll settle on to use.
2) Hack that display manager's pam file accordingly in the chroot.  For sake of
   example, let's say it's GDM.  So, we hack up $CHROOT/etc/pam.d/gdm
3) Hack the $CHROOT/etc/gdm/Xsession file accordingly to not start a local
   gdm session, but rather:
   ssh -X -S /socket 192.168.0.254 DISPLAY=ltsp20:0 gnome-session
   or whathave you.
4) ???
5) PROFIT!

Oh, and hack whatever startup scripts we have to launch $DM as opposed to ldm.

PROBLEMS LEFT TO SOLVE:

 * For the people interested in smart cards, I have no idear how they work at
   all.  I know ssh can interact with some smartcards, and I'm assuming that a
   smartcard pam module will somehow set an AUTHTOK that ssh can somehow use.
   Currently, I haven't got chaining in the pam module working quite correctly,
   since, although I set the AUTHTOK, I don't check to see if it's already set
   at the start (via the usual "try_first_pass" or "use_first_pass" mechanisms
   in pam modules), so we'll need to figure that out and add it in.
 * I have absolutely NO idea how we can bugger about, from a packaging point of
   view, with some of the files we'd need to touch.  Whatever display manager
   we'll settle on (maybe multiples; I'd expect the K crowd will want to use
   theirs, Gnomes will want to use GDM, etc.) we're going to have to do MAJOR
   messing about with it's config files in the chroot.  Something in the
   ltsp-build-client script, I'd expect.

Anyway, I'd be interested on hearing people's thoughts.  The people who were
interested in smart cards should take a role in hacking or testing this
pamifiaction process, since pam's going to be central to what they want to
accomplish.

-- 
Scott L. Balneaves | Words are a wonderful form of communication,
Systems Department | but they will never replace kisses and punches.
Legal Aid Manitoba |     -- Ashleigh Brilliant

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
_____________________________________________________________________
Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
For additional LTSP help,   try #ltsp channel on irc.freenode.net