Created attachment 2727 [details] Support a list of sockets on SSH_AUTH_SOCK 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 behavior of the ssh-agent (which will set SSH_AUTH_SOCK just for itself). Neither does it change the behavior 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 The idea has been discussed a little in these e-mail threads: http://lists.mindrot.org/pipermail/openssh-unix-dev/2015-September/034381.html and http://lists.mindrot.org/pipermail/openssh-unix-dev/2015-September/034406.html (the same patch is attached to the bug) In the second mail thread, there is a suggestion about adding a new environment variable (SSH_AUTH_SOCK_FALLBACKS) that also looks like a valid approach. Please, let me know your preferences and I can come up with whatever is better for openssh community.
Created attachment 2729 [details] Support a list of sockets on SSH_AUTH_SOCK (v2) Changes since v1: - Update SSH_AUTH_SOCK documentation
I was discussing this bug with Fabiano yesterday. The easiest way would be to ignore gnome-keyring, but if we would support this in openssh, even gnome-keyring can use this approach with list of sockets instead of overwriting the variable existing. About the patch, I asked Fabiano to write also some documentation, but two remarks: * First hunk in patch is wrong, because it remove "for" from "socket for ssh-add to work" (there is the catch about the .Nm) * The other hunks should contain at least the note about delimiter in the list. For example "If the variable contains a list of sockets separated by colon, the first functional socket will be used." Otherwise the patch is quite nice and small and I believe it can be useful feature for other tools and integration.
Created attachment 2730 [details] Support a list of sockets on SSH_AUTH_SOCK (v3) Changes since v2: - Address remarks done by Jakub Jelen Changes since v1: - Update SSH_AUTH_SOCK documentation
As asked by Damien, let me summarize why I do need this change on this bug report. Here is the rationale: As usually I am doing a considerable amount of development on Virtual Machines and usually I don't have their IP address to do an actual ssh agent forward, I started working in a way to do an "agent forward" over a spice channel and I am writing "agent forward" in quotation marks for a reason. There are operations that I really don't feel like forwarding to the client's agent (remote), like SSH_AGENTC_{ADD,REMOVE}_*_IDENTITY. IMO, adding/removing a key, should still be something that goes through the local agent inside the Virtual Machine. All the other operations, IMO, should have their result merged. For instance, SSH_AGENTC_REQUEST_RSA_IDENTITIES should return the identities from both the local and client's agent (remote), otherwise we would be bulldozing the local agent inside the Virtual Machine. So, that's the big view of my idea and that's the first reason that I have to have two agents running: the local agent and a "dispatcher" that talks to the client's agent (remote). The second reason (and the stronger one) is that when doing an agent-forward I should not mess with the agent running inside the Virtual Machine, I really should not break any kind of Desktop Environment integration and here the whole set of problems started. In my first implementation I tried to do: 1) Get the SSH_AUTH_SOCK var 2) Move the (local) socket created there to somewhere else 3) Create the client's socket (remote) in the same path as SSH_AUTH_SOCK 4) When disconnecting, move back the local agent socket to the same path as SSH_AUTH_SOCK That's a *really* *ugly* implementation, but it could have worked. The main problem is that GNOME is using Gnome Keyring's ssh-agent and it has an option that does replace the socket on SSH_AUTH_SOCK. If, somehow, for some reason, the user does that ... bye bye remote agent and my functionality is broken. So, I really know that my patch may be intrusive, but it is the last option that I have for having an agent-forward through a spice channel, completely Desktop Environment's agnostic. Any kind of suggestion on how to solve this situation without the need of multiple agents is more than appreciated.