[one-users] Some thoughts on ssh key authentication

[Javier Fontan]

Thanks, I really think that those are really nice ideas.

First of all using signing instead of plain encryption seems better
for authentication and also lets us use dsa keys. I am the one to
blame for the current ssh authentication :(

Using ssh key agent looks to me a much better usable system.

I think that this library will fit the bill
https://github.com/jordansissel/ruby-sshkeyauth. Probably these
modification can go along the proposal to specify the private key.

Anyway, there's some code contributed for x509 that also does the
signing way of authorizarion (http://dev.opennebula.org/issues/521).
Doing the same for ssh is perfectly parallel.



On Mon, May 9, 2011 at 11:04 PM, Lars Kellogg-Stedman
<lars at seas.harvard.edu> wrote:
> 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)
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>



-- 
Javier Fontan, Grid & Virtualization Technology Engineer/Researcher
DSA Research Group: http://dsa-research.org
Globus GridWay Metascheduler: http://www.GridWay.org
OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org