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

[Alexander Wuerstlein]

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.

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.

Another advantage of a separate environment variable is that existing
scripts and programs that replace or alter SSH_AUTH_SOCK won't interfere
with it and won't need to be changed. 


Ciao,

Alexander Wuerstlein.


[0] all whitespace like \n and \t would break some shellscript
    somewhere, simple spaces are sometimes used for directory names
    (think 'Program Files' or 'Application Data') and nonprintable ASCII
    characters would be even more of a pain to work with