[RFC][PATCH v2] Support a list of sockets on SSH_AUTH_SOCK

[Alexander Wuerstlein]

On 2015-09-27T11:23, Fabiano Fidêncio <fidencio at redhat.com> wrote:
> 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
> >
> > 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?

Not really. As I've said, I can easily change that colon to something
that works. And, if you take my suggestion, SSH_AUTH_SOCK would work as
before. So it would only be necessary to change anything if I were to
start using SSH_AUTH_SOCK_FALLBACKS. 

> 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)?

I think if its a new environment variable, nobody will use it in old
scripts, so there is no cause for a warning in advance. But I'm not sure
what actual openssh developers have to say about this (I'm just reading
the mailing list...).



Ciao,

Alexander Wuerstlein.