Pawel Krupinski's ssh-decrypt ssh-encrypt proposal

[Peter Stuge]

On Thu, Nov 23, 2006 at 09:14:01AM +0000, Pawel Krupinski wrote:
> > http://www.gentoo.org/proj/en/keychain/ may also be
> interesting.
> 
> It is interesting and actually it is something I have
> in my mind as a backup solution... 
> 
> In my case: we are using OpenSSH, so we have
> infrastructure to support OpenSSH based solution. With
> gpg

Keychain linked to above is not for use with GnuPG.


> If I fail to convince you, we either:
> 1. Support this solution internally (hopefully you are
> not changing ssh-agent interface too often ;-)));

I'm not sure if it has ever changed, except when support for
SSH2 was added. It is quite stable.


> One question regarding keychain. Quoting the keychain
> page: "It acts as a front-end to ssh-agent". Do you
> guys work with them to make sure that patches/changes
> to the API don't affect their solution? This is the
> only thing that puts us off from the internal support,
> so wondering how others handling it. 

Not at all.


> > As for ssh-agent, I'm not sure I want it to do any 
> > tricks. I trust it
> > with my keys so I want it to be REALLY simple.
> 
> Well, not sure if I called it a trick -

What I mean by that is that I personally don't want ssh-agent to do
anything but the least neccessary for forwarded ssh authentication
needs, ie. sign a challenge with my key. I see the agent as a
critical component. Adding code to it must be done with caution, for
a good reason.


> "give passphrase once, use private key multiple times" is
> what ssh-agent is for ;-)))

Not really that generically, no. It's only for using the private key
to authenticate a user through a forwarded channel.

This is my point: The private key is used to authenticate the user
(perform a signature) but I would like to stay there and not allow
any other use of the key. Even if it theoretically boils down to the
same mathematical operation for RSA it's a different code path so a
little different in practise, and maybe a lot different for other
algorithms, subjecting my keys to even greater risk.


> Currently there is another tool ssh-sign

I couldn't find it, but since signing is what the agent does I assume
ssh-sign works without modifications in the agent.


> and using the configuration file you can turn it on and off.
> The same can be applied to ssh-{en|de}crypt.

You could probably sell me a compile-time option. But I'm not sure
what opinion the OpenSSH developers have on this. There are a lot of
options already.


> If this change would require changes to API etc, I
> wouldn't have put forward this solution,

It does. But don't let that stop you! If you like it, maybe someone
else will too. I am by no means a single OpenSSH authority, only when
it comes to what I want running on my systems. :)


> but as these changes seems pretty easy, I think it is worth it.

To be honest I think no change (as in broader API, added
functionality) to ssh-agent is worth this increase in risk.


> It seems there were some maintenance things going on
> yesterday with the server, so I will repost my
> yesterday's e-mail:

I got it, but maybe it was delayed.


> As I said it was just a very quick PoC, but if it is
> of interest to OpenSSH, I can develop it correctly
> over the next few days and have it up and ready on
> Monday.

I would interpret the limited response to mean that there
isn't great interest.


> One question regarding the interface. As ssh-agent can
> have multiple keys, what would be the best way to
> determine which one to use ? Sending the public part?
> Currently I'm trying out all keys and it is not the
> best possible option...

The user should probably select which key to use. You could use
SSH2_AGENTC_REQUEST_IDENTITIES to get a list from the agent. See
what ssh-add -l does. Beware of inconsistencies between selection
time and decryption time if you intend to use an index for selection.

Anyway, nothing is of course stopping you from maintaining this
functionality separately. I would be very surprised if you had to
update the authfd.[ch]/ssh-agent.c patch even once a year.

Oh, and for future reference, please always send unified diffs with a
few context lines. diff -u produces this output, it is much more
readable to most, plus the context is good to not make a complete
mess if the file to be patched has changed since the patch was
produced. Thanks!


//Peter