[RFE] Multiple ssh-agent support

[Fabiano Fidêncio]

Okay, okay.

I have tested a few ideas and what ended up working better for me was:
1) have a spice-ssh-agent.sh installed in my /etc/profile.d
2) get the system's SSH_AUTH_SOCK and prepend the path to the
spice-ssh-agent's socket there.

I tested this with different DEs, using Fedora and it seems to work as expected.

So, can we move further with the SSH_AUTH_SOCK containing a list of
sockets? Please, the idea is _NOT_ to talk to all of the sockets, is
just to have a second socket working in the case where the first one
breaks/is not available.

Is this the right place to drop a patch to openssh adding this to the agent?

Looking forward for answers!
Best Regards,
--
Fabiano Fidêncio

On Mon, Sep 21, 2015 at 8:14 AM, Fabiano Fidêncio <fidencio at redhat.com> wrote:
> On Mon, Sep 21, 2015 at 7:40 AM, Philipp Marek <philipp.marek at linbit.com> wrote:
>>> > unlinking the socket seems a bit overkill. You could play with
>>> > SSH_AUTH_SOCK
>>>
>>> Playing with SSH_AUTH_SOCK may be a bit problematic. As far as I
>>> understand it would require a session restart in order to set a new
>>> value to the env var (at least using GNOME).
>>> Btw, I would like to be really clear here that I am focused in a
>>> DE-agnostic solution. :-)
>> Well, just move the existing socket aside (to another name in the same
>> directory), and have your spice agent provide a socket with the original
>> name.
>
> Here it breaks gnome-keyring-daemon --replace.
> I mean, if I takeover the gnome-keyring agent socket path (always in
> /run/user/$uid/keyring/ssh), when the user runs gnome-keyring-daemon
> --replace it replaces my spice-agent :-\
>
>>
>>> > I also like the idea of SSH_AUTH_SOCK containing a list of sockets.
>> Uh, that sounds like more complexity - and that means more code.
>> As the ssh-agent is handling private keys, it should be as small as
>> possible - forwarding queries to only one (the next one) is enough for
>> this use case.
>>
>>
>>> The proxy agent would be the spice one or the one already running in the system?
>> I guess that the spice-agent wouldn't add keys back to the developer
>> machine; that runs a bit against having the key on the VM (and only the
>> VM), if it routinely gets moved across the network.
>>
>> So I guess the spice agent would need to provide it, by storing it in the
>> VM system agent.
>>
>
> I agree here.