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. It works as you can see in these small demo videos: https://fidencio.fedorapeople.org/ssh-agent-forward/ Now where the problem starts: doing this would break the desktop integration with its running ssh-agent. 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). But how to do that? What could be a good approach for doing that? Expand the agent protocol in order to have a "ssh-add --proxy /path/to/the/new/agent/socket" can be one option. Making SSH_AUTH_SOCK support a list of agents is another option, then the first agent would be the "dispatcher". These are the questions that I have and I am open to suggestions/further discussions. Best Regards, -- Fabiano Fid?ncio
Fabiano Fid?ncio wrote:> 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). > > But how to do that? What could be a good approach for doing that?One obvious approach is to create a proxy agent which looks like an agent to all clients, but which also integrates with SPICE. //Peter
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_SOCK> 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.
On Fri, Sep 18, 2015 at 7:07 PM, Peter Stuge <peter at stuge.se> wrote:> Fabiano Fid?ncio wrote: >> 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). >> >> But how to do that? What could be a good approach for doing that? > > One obvious approach is to create a proxy agent which looks like an > agent to all clients, but which also integrates with SPICE.This is a good solution, probably the best one. The main problem is how to implement it. We have two clear ways for adding a proxy agent. One is with the SSH_AUTH_SOCK supporting a list of sockets, but it won't be dynamically. In other words, if I want to replace the spice-agent for another one, it would, most likely, require a session restart and it's not exactly good :-\ The other option would be extend the ssh-agent protocol to support a few new operations (add/remove the proxy agent) and then we could just do a ssh-add --proxy path/to/the/socket ... I am really would prefer to go for the second approach, but I really would like to hear, from you (ssh people), if it would be accepted and if I can proceed with the implementation. Best Regards, -- Fabiano Fid?ncio
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