Alexander, On Sun, Sep 27, 2015 at 4:45 AM, Alexander Wuerstlein <arw@xxxxxxxxx> wrote: > On 2015-09-26T03:47, Fabiano Fidêncio <fidencio@xxxxxxxxxx> 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
