| Summary: | Support a list of sockets on SSH_AUTH_SOCK | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Fabiano Fidêncio <fabiano> | ||||||||
| Component: | ssh-agent | Assignee: | Assigned to nobody <unassigned-bugs> | ||||||||
| Status: | NEW --- | ||||||||||
| Severity: | enhancement | CC: | fabiano, jjelen | ||||||||
| Priority: | P5 | ||||||||||
| Version: | 7.1p1 | ||||||||||
| Hardware: | Other | ||||||||||
| OS: | Linux | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Fabiano Fidêncio
2015-10-13 22:19:21 AEDT
Created attachment 2729 [details]
Support a list of sockets on SSH_AUTH_SOCK (v2)
Changes since v1:
- Update SSH_AUTH_SOCK documentation
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. Created attachment 2730 [details]
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
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.
|