[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-rfe
Subject:    Re: [osol-rfe] Solution to pam_ldap + ssh public keys
From:       "Richard L. Hamilton" <rlhamil () smart ! net>
Date:       2007-11-23 22:06:08
Message-ID: 28069017.1195884398502.JavaMail.Twebapp () oss-app1
[Download RAW message or body]

> How about the reverse - the equivalent of
> pam_ssh_agent to
> use a login password authenticated by other means to
> unlock one's
> ssh keys and start an ssh-agent process (and pass on
> the appropriate environment
> variables)?
> 
> Much better if it could also support resetting the
> ssh password, to keep it in
> sync with the login password.
> 
> This has the advantage that the authentication is
> centrally controlled, yet
> one still only has to enter one password for both
> logging in and unlocking
> one's ssh keys.
> 
> If e.g. mozilla/firefox/thunderbird/etc could also
> use that to unlock certs,
> that would be great.  If ssh and other apps could
> access PKI certs and keys
> stored in an LDAP server (after authentication), that
> would be another
> route, and even encrypted keys would then not be
> stored in user directories.
> 
> But then this also has to all work somehow with
> Kerberos authentication etc
> to give single sign-on to WIndows, too, right? :-)
>  Not to mention whatever
> ardware tokens people want to throw in there...


BTW, I got pam_ssh_agent working finally; the problem was that it needed
to find keychain with a minimal PATH, i.e. in /usr/bin.

That's only with NIS, not anything trickly like LDAP (which is to say I don't know if that
would work).  Still, it seems convenient.

So, in addition to the pam.conf entry for pam_ssh_agent.so.1, I also have the following
in my $HOME/.dtprofile:

keychain && . "${HOME}/.keychain/`uname -n`-sh" >/dev/null 2>&1
ssh-add -l >/dev/null 2>&1 || env SSH_ASKPASS=/usr/local/bin/ssh-askpass ssh-add </dev/null

(the seccond line being for the sake of an older system to which pam_ssh_agent can't be ported
for lack of unsetenv(3c); but harmless if not applicable - as such, I rather wish unsetenv() were
backported to at least Solaris 9, since there is a fair bit of code out there that needs it)

I mention this because I'd rather like to see pam_ssh_agent (and keychain) added to OpenSolaris.
Given the issues I mentioned, getting it working is pretty easy.  However, I don't know if the LGPL
will be a problem, or if it would pass the examination of someone with a sensibly paranoid view
of security.
 
 
This message posted from opensolaris.org
_______________________________________________
opensolaris-rfe mailing list
opensolaris-rfe@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]