Unfortunately, I'm at home for the holidays, and my laptop is having modem
problems which isolate it from the remainder of the world. I'll submit a
patch
to this list as soon as I get these problems worked out.
The code is very simple; I just modified the readpass.{c,h} files to check
whether a keychain item with the same name as the password prompt exists, and
if so to use the password from the keychain, before calling the BSD
readpassphrase function. If the user types in a password at the prompt, ssh
asks whether that password should be stored on the keychain. Of course, I also
changed configure.ac to check whether a program using the Keychain API compiles
(this check only occurrs if the system name includes "darwin") before
enabling
the feature. If I get some time, I'll add the following improvements: 1)
allow
the user to choose not to use the stored password in the keychain and proceed
to the prompt 2) allow the user to designate certain passwords as non-saveable,
so he or she isn't prompted and forced to say "no" every time he
or she types a
password.
Someone asked how the system knows it's running a GUI so it can display
the "unlock keychain" dialog. I don't know precisely how Apple
does this, but
if you ask for a password from a locked keychain, the system automatically
calls the unlock function, which is able to display the necessary window
widgets. Since OS X always runs the GUI (except in single user mode), I
don't
imagine that this is very complicated.
I'm not an expert on your policy about including code which uses non-open-
source APIs, but I'll post a patch to this list anyway as soon as my
computer's
modem issue is resolved.
Sorry to keep you waiting.
Will
> Message: 1
> Date: Sun, 21 Dec 2003 23:43:45 -0600
> From: Jeremy McMillan <aphor at speakeasy.net>
> Subject: Re: openssh-unix-dev Digest, Vol 8, Issue 15
> To: openssh-unix-dev at mindrot.org
> Message-ID: <CEB70485-3441-11D8-B722-00039384AB40 at speakeasy.net>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> I think what Mr. Farr is referring to is keychain support. Keychain is
> provided as part of OS X. Apple published an API for it. An OS X
> compile would store and retrieve keys from Keychain in lieu/addition to
> the SSH Agent. Keychain is to OS-X what the ssh-agent is to ssh. This
> makes perfect sense, and I haven't been sufficiently peeved to do this
> yet, but I have dreamt of this myself.
>
> It really should be up in the sysdep stuff. That way you can distribute
> a tarball. People can test that, and later it can get merged into the
> ssh tree.
>
> For now, I, if not others, am interested in this code. Please do share:
> either diffs or tarball!
>
> On Dec 21, 2003, at 11:11 PM, Damien Miller <djm at mindrot.org>
wrote:
>
> > Date: 20 Dec 2003 07:40:32 +1100
> > From: Damien Miller <djm at mindrot.org>
> > Subject: Re: Mac OS X Keychain Support
> > To: "Will M. Farr" <farr at MIT.EDU>
> > Cc: openssh-unix-dev at mindrot.org
> > Message-ID: <1071866432.31141.10.camel at sakura.mindrot.org>
> > Content-Type: text/plain
> >
> > On Sat, 2003-12-20 at 04:56, Will M. Farr wrote:
> >> Hello,
> >>
> >> I'm a Mac OS X user, and I got tired of typing my password
every time
> >> I
> >> want to login, but didn't want to use ssh-agent and the like.
So, I
> >> grabbed the code for OpenSSH 3.7p1, and made some modifications
which
> >> allow passwords to be stored and recalled from the OS X Keychain.
The
> >> reason I'm posting to this list is that I'd like to make
these
> >> modifications available to others, and I'm curious whether you
would
> >> be
> >> interested in including them in OpenSSH; I know that this is
pretty
> >> operating-system specific (as far as I know, keychain is unique to
OS
> >> X), but I changed configure.ac to test for keychain support when
it
> >> detects a darwin operating system, so it shouldn't bother
people who
> >> don't have mac os X. Should I diff my code against the
standard 3.7p1
> >> and give you guys a patch?
> >
> > Is the OS X KeyChain fhee software? If so, then send a patch to this
> > list.
> >
> > -d
> >
> ---
> Jeremy McMillan
>
>