An additional authorization mechanism (SSH keys)

[David Zeuthen]

Hi,

On Fri, Apr 15, 2011 at 6:25 PM, Pavel Strashkin
<pavel.strashkin at gmail.com> wrote:
> What do you think about authorization via SSH keys?

Nitpick: It's authentication, not authorization.

> From client side:
> 1. Read ~/.ssh/id_rsa.pub (public key) and send it to server
>
> From server side:
> 1. Recv public key
> 2. Read a list of keys from ~/.ssh/authorized_keys (or any other file,
> depend on settings)
> 3. Compare received public key with a list of keys from step 2

I think this is backwards since it would authenticate anyone that has
your public SSH key. In fact (since we don't support TLS in libdbus-1
at all), said public key would be sent in the clear and thus easy to
intercept by any eavesdropper. And since the public key is all you
need, the eavesdropper can now authenticate as you. So I don't think
this is a good idea.

IIRC, the way SSH authentication normally works is that the client
wanting to connect has the private key and the server being connected
to has the public key in ~/.ssh/authorized_keys for the user. And
IIRC, the client never reveals its private key but does it prove to
the server that it has the key by being able to decrypt something
being sent to the key (this of course depends on strong encryption).

We could do something similar in to what ssh(1) is doing (as sketched
out in the paragraph above), but I don't think we should because it's
just as easy to tunnel the D-Bus traffic over TLS and do the
authentication at that lower level and then just use the ANONYMOUS
auth method at the D-Bus level.

With my distributor hat on, I also don't want libdbus-1 or libgio-2.0
(another D-Bus implementation) to use strong encryption if i can avoid
it (on the distributor side, suddenly a lot more red tape gets added
if you do that).

     David