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 <[email protected]> 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... [email protected]' > > 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 <[email protected]> > Senior Technologist > Harvard University SEAS > Academic and Research Computing (ARC) > _______________________________________________ > Users mailing list > [email protected] > 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 _______________________________________________ Users mailing list [email protected] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
