On Fri, Sep 18, 2015 at 10:58 PM, ?ngel Gonz?lez <keisial at gmail.com> wrote:> On 18/09/15 15:47, Fabiano Fid?ncio wrote: >> >> Howdy! >> >> I've been working on a prototype that allows to do ssh-agent forward >> between a guest, using SPICE, and a spice client >> (remote-viewer/virt-viewer/spicy) >> The whole idea is to have something similar to "ssh -A guest", but >> integrated with the desktop environment. >> >> As a proof of concept I wrote a standalone ssh-agent that _unlink_ the >> current running agent in the guest machine and creates its socket in >> the same path used by the old agent. > > unlinking the socket seems a bit overkill. You could play with > SSH_AUTH_SOCKPlaying 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. :-)> > > >> A few possible solutions for this would involve a way to support more >> than one agent, talking to both (the local one and the spice one), >> merging then their responses and returning it to any application who >> sent the request. Note that would be really nice if we can limit it to >> do just some operations (like, ssh-add .ssh/id_rsa probably must not >> go to the spice agent). >> > 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?). > > I also like the idea of SSH_AUTH_SOCK containing a list of sockets. >The proxy agent would be the spice one or the one already running in the system? This part is very important, because when you are doing a ssh-add .ssh/id_rsa you really want the key to be added to your system agent (it means, gnome-keyring-daemon agent or ssh-agent, depending on the DE you're using). Considering we want to have the system agent as a dispatcher ... how would we add a second agent to it without extending the protocol? Again, adding it to SSH_AUTH_SOCK may be a solution, but then all DEs must add the spice agent socket path independently if it's running or not. That's the reason I still think that having a ssh-add -p path/to/the/socket would be better. It could be dynamically set and would not require a DE session restart. Best Regards, -- Fabiano Fid?ncio
> > 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.
On Mon, Sep 21, 2015 at 7:40 AM, Philipp Marek <philipp.marek at linbit.com> 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.