> > 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. > > I would make a proxy ssh agent that linearly attempts from each > > child agent. The add operations would always go to the first agent > > (unless it returned an error?). That sounds easy enough - after moving the "original" socket aside, fall back to queries on that one if the "new" agent can't answer. That way we'd get a chain of agents, each asking the "older"/previous if needed. > > 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
