Re: pam_sshauth update - status update, ready for hacking?

On Tue, Mar 22, 2011 at 09:52:37AM -0500, Scott Balneaves wrote:

By way of an update, I've progressed reasonably well along getting things to
work.

If any of you have been watching the branch, you'll see that as I've been
hacking on this, I've been fleshing out the pam_sshauth package.

Last night, I was able to actually log in.  I don't have any plumbing yet for
starting a remote desktop session, however, I did get a local xterm to pop up.
The xterm was owned by the user who logged in, which was cool.

Here's a rough thumbnail sketech of what I had to do to get that going.

 * In the chroot, I installed the build-essential package, and the deps needed
   to compile the pam_sshauth package.  Did a "make dist" in the upstream
   bzr dir of pam_sshauth to get a tarball, and dropped it into the chroot, and
   compiled it there (my server's 64 bit, and the chroot's 32, so that's the
   reason for that extra step).  Remember to ./configure --prefix=/usr so the
   make install will go to the right places.
 * Install xdm in the chroot.
 * Copy the ltsp-session script from the pam_sshauth package to $CHROOT/usr/bin
 * Edit the $CHROOT/etc/pam.d/xdm file.  The relevant lines I modified were:
   - Comment out the "common-auth" line, since we're authenticating with
     our pam module
   - Add the following lines:

auth    required  pam_sshauth.so debug nostrict host=192.168.0.254
auth    required  pam_exec.so expose_authtok /usr/bin/ltsp-session
session required  pam_exec.so /usr/bin/ltsp-session

 * I installed the nss_extrausers package, and modified the
   $CHROOT/etc/nsswitch.conf file appropriately.
 * On the server, I had to add the user I was testing as into the "shadow"
   group to allow the "getent shadow $USER bit to return something.

Rebuild the chroot, and voila.  I may have forgotton some steps (I'm doing this
from memory) but anyone trying to duplicate this should get reeeaaal close with
these steps.

Booting the terminal, the familiar old xdm screen came up, login and password
as normal, and the screen changed to a borderless xterm in the upper left
corner.  Tunnel was sitting there nicely.  Typing 'exit' in the xterm resulted
in the ltsp-session part being called cleanly from the pam close_session, and
the tunnel was shut down nicely, and references in the
$EXTRAFILES/passwd,group,shadow files were removed cleanly as well.  SWEET.

Problems left to solve, and how I think I'll solve them:

 * Adding the users to the shadow group doesn't seem right.  I haven't tested
   yet, but I'm assuming that if the users about to expire, or something like
   that, that the ssh on the server will tell them about this through the pam
   conversation, as opposed to me having to actually bring down their line in
   the shadow file.  If that's the case, then simply echoing "$USER:*:::::::"
   to the local shadow file will be enough to make xdm happy.  If not, for
   whatever silly reason, all we need to do is write a simple setuid helper
   program that will do a "getspnam()" call, null out the returned password,
   and return the shadow line for that user, but my suspicion is that won't be
   necessary.
 * During the "auth" phase, the tunnel's created so that we can bring down the
   passwd, group, and (possibly) shadow entries needed to satisfy xdm.  At this
   point, when the tunnel's created, it's created as root.  By the time we
   progress down to the session phase of pam, and indeed, the session scripts
   in xdm, we've dropped priv's down to the user, making our tunnel useless, as
   it's owned by root.  Oooops.  A simple chown of the tunnel doesn't work (I
   tried).  So, we'll have to establish the tunnel twice: once as root to bring
   down the bits we need during the auth phase, and once as the user to
   actually launch our session.  This will require some changes to the
   shm_askpass helper, since it'll have to keep the password around a while
   longer, and change the permissions on the shared memory segment.  I've
   already got a firm idea in my mind how this will work.

I have a basketball tourney my son's attending in Sask. starting tomorrow, so I
won't get much of a chance to hack on this again 'till next week.

Hope this excites all of you as much as it does me.

Cheers,
Scott

-- 
Scott L. Balneaves | I must have a prodigious quantity of mind; it takes me
Systems Department | as much as a week sometimes to make it up.
Legal Aid Manitoba |     -- Mark Twain, "The Innocents Abroad"

------------------------------------------------------------------------------
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