Linux in-kernel keys support

David Härdeman david at
Wed Jul 27 20:20:15 EST 2005

Damien Miller (djm at wrote:
> On Tue, 26 Jul 2005, David wrote:
> > Hi all,
> >
> > I recently made a patch to openssh 4.1p1 to allow it to use the
> > in-kernel key management provided by 2.6.12 or later Linux kernels.
> I'm not sure I understand this: just the patch just make ssh store and
> retrieve user authentication pubkeys from the kernel key store? It doesn't
> appear to any kernel facilities to do the actual signing of challenges.
> -d

Ummm, sorry if my first mail was unclear...

The patch allows ssh-add to (optionally) store the secret ssh keys in the
Linux kernel key storage. The key storage facility has no concept of signing
challenges etc, so ssh is also patched to read the keys from the kernel key
storage and to use them directly (much like it would read your keys from the
.ssh dir if you would run ssh with no ssh-agent running)

So the advantage is mainly that you can keep a bunch of ssh keys around
without having to keep track of any ssh-agents (in my case, I wanted the ssh
keys to be auto-loaded using udev when I inserted a usb-key, esentially using
it as a cheaper smartcard). This also means that if you add keys during an X
session and then continue to work on the console and log out of X, the keys
will still be available. Also, as the keys are stored in the user session
keyring, they are automatically wiped when the user is no longer logged into
the computer.

The disadvantage is that the kernel key storage doesnt support two things that
the agent supports: signing challenges and asking for confirmation before
allowing the use of a key. The former implies that secret keys are readable
(by the user who added them) from the kernel which might not be wise from a
security point-of-view.

On the other hand, if someone was to break into your account, and thus was
able to read the secret keys from the kernel....I imagine that he/she could
already do similar things by reading the memory of the ssh-agent and/or using
it to log into other machines...

I hope that cleared things up a, is the idea somewhat sane or is it


More information about the openssh-unix-dev mailing list