[RFC][PATCH v2] Support a list of sockets on SSH_AUTH_SOCK
Fabiano Fidêncio
fidencio at redhat.com
Sun Sep 27 19:23:58 AEST 2015
Alexander,
On Sun, Sep 27, 2015 at 4:45 AM, Alexander Wuerstlein <arw at cs.fau.de> wrote:
> On 2015-09-26T03:47, Fabiano Fidêncio <fidencio at redhat.com> wrote:
>> The idea behind this change is to add support for different "ssh-agents"
>> being able to run at the same time. It does not change the current
>> behaviour of the ssh-agent (which will set SSH_AUTH_SOCK just for
>> itself). Neither does it change the behaviour of SSH_AGENT_PID (which
>> still supports only one pid).
>> The new implementation will go through the list of sockets (which are
>> separated by a colon (:)), and will return the very first functional
>> one. An example of the new supported syntax is:
>> SSH_AUTH_SOCK=/run/user/1000/spice/ssh:/tmp/ssh-hHomdONwQus6/agent.6907
>
> I think changing the semantics of SSH_AUTH_SOCK may be problematic. I'm
> currently using a few scripts that create a socket per X display, named
> like '/path/somewhere/:17.agent'. The choice of ':' as a separator would
> of course break those scripts.
Your point really make sense.
This is the first approach that came to my mind and could be
acceptable by the community (according to the discussions I linked in
the email).
But seems that now we have a better option ...
>
> While my personal problem described above is easily fixable, I think the
> bigger picture is: No choice[0] of separator character is possible that
> won't break existing usage. Therefore I'd rather suggest introducing a
> separate SSH_AUTH_SOCK_FALLBACKS environment in addition to
> SSH_AUTH_SOCK. SSH_AUTH_SOCK_FALLBACKS would then be used as the list of
> fallbacks if SSH_AUTH_SOCK is not working currently.
... because I this idea sounds better than the initial approach.
OTOH, we still have the problem about the separator as using a colon
would break your fallbacks as well.
Do you have some suggestion about this? Or as it is a new env var we
can just warn the users and then they will have enough time for
changing their scripts (like in your case)?
Best Regards,
---
Fabiano Fidêncio
More information about the openssh-unix-dev
mailing list