Okay, okay. I have tested a few ideas and what ended up working better for me was: 1) have a spice-ssh-agent.sh installed in my /etc/profile.d 2) get the system's SSH_AUTH_SOCK and prepend the path to the spice-ssh-agent's socket there. I tested this with different DEs, using Fedora and it seems to work as expected. So, can we move further with the SSH_AUTH_SOCK containing a list of sockets? Please, the idea is _NOT_ to talk to all of the sockets, is just to have a second socket working in the case where the first one breaks/is not available. Is this the right place to drop a patch to openssh adding this to the agent? Looking forward for answers! Best Regards, -- Fabiano Fidêncio On Mon, Sep 21, 2015 at 8:14 AM, Fabiano Fidêncio <fidencio@xxxxxxxxxx> wrote: > On Mon, Sep 21, 2015 at 7:40 AM, Philipp Marek <philipp.marek@xxxxxxxxxx> wrote: >>> > unlinking the socket seems a bit overkill. You could play with >>> > SSH_AUTH_SOCK >>> >>> Playing with SSH_AUTH_SOCK may be a bit problematic. As far as I >>> understand it would require a session restart in order to set a new >>> value to the env var (at least using GNOME). >>> Btw, I would like to be really clear here that I am focused in a >>> DE-agnostic solution. :-) >> Well, just move the existing socket aside (to another name in the same >> directory), and have your spice agent provide a socket with the original >> name. > > Here it breaks gnome-keyring-daemon --replace. > I mean, if I takeover the gnome-keyring agent socket path (always in > /run/user/$uid/keyring/ssh), when the user runs gnome-keyring-daemon > --replace it replaces my spice-agent :-\ > >> >>> > I also like the idea of SSH_AUTH_SOCK containing a list of sockets. >> Uh, that sounds like more complexity - and that means more code. >> As the ssh-agent is handling private keys, it should be as small as >> possible - forwarding queries to only one (the next one) is enough for >> this use case. >> >> >>> The proxy agent would be the spice one or the one already running in the system? >> I guess that the spice-agent wouldn't add keys back to the developer >> machine; that runs a bit against having the key on the VM (and only the >> VM), if it routinely gets moved across the network. >> >> So I guess the spice agent would need to provide it, by storing it in the >> VM system agent. >> > > I agree here. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
