[one-users] Some thoughts on ssh key authentication

[Lars Kellogg-Stedman]

Hello all,

We've been working hard to get our user community to understand the
risks associated with storing private ssh keys on shared filesystems
or shared access computers.  Along similar lines, we're also trying to
avoid the use of tools that cache passwords in the same places.  This
means that both of the existing authentication mechanisms currently
offered by OpenNebula are somewhat difficult for us to use.  While we
could simply ask people to generate unique keys for the OpenNebula
environment, it occurred to me that it should be possible to implement
an authentication mechanism that makes use of ssh-agent for proxied
access to a user's private key, with the following advantages:

- Private keys could be stored on someone's "local" computer, even if
all ONE access is through some sort of head node.
- The ONE tools (e.g., oneauth) would never need direct access to the
private key

While I haven't actually implemented an authentication mechanism that
does this, I've spent some time researching everything that would be
required and I've put together the following two articles:

- http://blog.oddbit.com/2011/05/converting-openssh-public-keys.html

  This article takes a look at how OpenSSH stores public keys and how
they can be converted into other formats.

- http://blog.oddbit.com/2011/05/signing-data-with-ssh-agent.html

  This article examines how to programatically interact with ssh-agent
for signing and how to verify signatures.

I think implementing an authentication module based on this
information shouldn't be terribly difficult.  The mechanism would look
like this:

- On the client side, 'oneauth login' would generate a
username:timeout token and sign it using either a locally available
private key or the ssh agent.
- The auth token + signature would be passed to the server as the
authentication credential.
- The server would use the ssh public key to verify the signature.

A key feature here is that the server would be able to use the ssh
public key directly, rather than requiring the end user to run
'oneauth key'.  So creating a user for this authentication mechanism
would look something like:

  oneuser create lars 'ssh-rsa AAAAB3NzaC1... lars at seas.harvard.edu'

I'm curious what other people think of this idea.  Does this make
sense?  Do you see it as an improvement over the existing mechanism?
Is there work going on that would make this unnecessary?

Cheers,

-- 
Lars Kellogg-Stedman <lars at seas.harvard.edu>
Senior Technologist
Harvard University SEAS
Academic and Research Computing (ARC)