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
