openssh bugs - Oct 2015 - [Bug 2480] New: Support a list of sockets on SSH_AUTH_SOCK

https://bugzilla.mindrot.org/show_bug.cgi?id=2480

            Bug ID: 2480
           Summary: Support a list of sockets on SSH_AUTH_SOCK
           Product: Portable OpenSSH
           Version: 7.1p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh-agent
          Assignee: unassigned-bugs at mindrot.org
          Reporter: fabiano at fidencio.org

Created attachment 2727
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2727&action=edit
Support a list of sockets on SSH_AUTH_SOCK

The idea behind this change is to add support for different
"ssh-agents"
being able to run at the same time. It does not change the current
behavior of the ssh-agent (which will set SSH_AUTH_SOCK just for
itself). Neither does it change the behavior of SSH_AGENT_PID (which
still supports only one pid).
The new implementation will go through the list of sockets (which are
separated by a colon (:)), and will return the very first functional
one. An example of the new supported syntax is:
SSH_AUTH_SOCK=/run/user/1000/spice/ssh:/tmp/ssh-hHomdONwQus6/agent.6907

The idea has been discussed a little in these e-mail threads:
http://lists.mindrot.org/pipermail/openssh-unix-dev/2015-September/034381.html
and
http://lists.mindrot.org/pipermail/openssh-unix-dev/2015-September/034406.html
(the same patch is attached to the bug)

In the second mail thread, there is a suggestion about adding a new
environment variable (SSH_AUTH_SOCK_FALLBACKS) that also looks like a
valid approach. Please, let me know your preferences and I can come up
with whatever is better for openssh community.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2480

Fabiano Fid?ncio <fabiano at fidencio.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fabiano at fidencio.org

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2480

Fabiano Fid?ncio <fabiano at fidencio.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2727|0                           |1
        is obsolete|                            |

--- Comment #1 from Fabiano Fid?ncio <fabiano at fidencio.org> ---
Created attachment 2729
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2729&action=edit
Support a list of sockets on SSH_AUTH_SOCK (v2)

Changes since v1:
- Update SSH_AUTH_SOCK documentation

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2480

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com

--- Comment #2 from Jakub Jelen <jjelen at redhat.com> ---
I was discussing this bug with Fabiano yesterday. The easiest way would
be to ignore gnome-keyring, but if we would support this in openssh,
even gnome-keyring can use this approach with list of sockets instead
of overwriting the variable existing.

About the patch, I asked Fabiano to write also some documentation, but
two remarks:
 * First hunk in patch is wrong, because it remove "for" from
"socket
for ssh-add to work" (there is the catch about the .Nm)
 * The other hunks should contain at least the note about delimiter in
the list. For example "If the variable contains a list of sockets
separated by colon, the first functional socket will be used."

Otherwise the patch is quite nice and small and I believe it can be
useful feature for other tools and integration.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2480

Fabiano Fid?ncio <fabiano at fidencio.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2729|0                           |1
        is obsolete|                            |

--- Comment #3 from Fabiano Fid?ncio <fabiano at fidencio.org> ---
Created attachment 2730
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2730&action=edit
Support a list of sockets on SSH_AUTH_SOCK (v3)

Changes since v2:
- Address remarks done by Jakub Jelen

Changes since v1:
- Update SSH_AUTH_SOCK documentation

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2480

--- Comment #4 from Fabiano Fid?ncio <fabiano at fidencio.org> ---
As asked by Damien, let me summarize why I do need this change on this
bug report.

Here is the rationale:
As usually I am doing a considerable amount of development on Virtual
Machines and usually I don't have their IP address to do an actual ssh
agent forward, I started working in a way to do an "agent forward"
over a spice channel and I am writing "agent forward" in quotation
marks for a reason.
There are operations that I really don't feel like forwarding to the
client's agent (remote), like SSH_AGENTC_{ADD,REMOVE}_*_IDENTITY. IMO,
adding/removing a key, should still be something that goes through the
local agent inside the Virtual Machine.
All the other operations, IMO, should have their result merged. For
instance, SSH_AGENTC_REQUEST_RSA_IDENTITIES should return the
identities from both the local and client's agent (remote), otherwise
we would be bulldozing the local agent inside the Virtual Machine.

So, that's the big view of my idea and that's the first reason that I
have to have two agents running: the local agent and a "dispatcher"
that talks to the client's agent (remote).

The second reason (and the stronger one) is that when doing an
agent-forward I should not mess with the agent running inside the
Virtual Machine, I really should not break any kind of Desktop
Environment integration and here the whole set of problems started.
In my first implementation I tried to do:
1) Get the SSH_AUTH_SOCK var
2) Move the (local) socket created there to somewhere else
3) Create the client's socket (remote) in the same path as
SSH_AUTH_SOCK
4) When disconnecting, move back the local agent socket to the same
path as SSH_AUTH_SOCK

That's a *really* *ugly* implementation, but it could have worked. The
main problem is that GNOME is using Gnome Keyring's ssh-agent and it
has an option that does replace the socket on SSH_AUTH_SOCK. If,
somehow, for some reason, the user does that ... bye bye remote agent
and my functionality is broken.

So, I really know that my patch may be intrusive, but it is the last
option that I have for having an agent-forward through a spice
channel, completely Desktop Environment's agnostic.

Any kind of suggestion on how to solve this situation without the need
of multiple agents is more than appreciated.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2480

Celeste Liu <CoelacanthusHex at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |CoelacanthusHex at gmail.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.