Re: [RFC][PATCH v2] Support a list of sockets on SSH_AUTH_SOCK

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



On Mon, Sep 28, 2015 at 8:26 AM, Philipp Marek <philipp.marek@xxxxxxxxxx> wrote:
>> > 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
>> > behaviour of the ssh-agent (which will set SSH_AUTH_SOCK just for
>> > itself). Neither does it change the behaviour of SSH_AGENT_PID (which
>> > still supports only one pid).
>>
>> Conceptually, it seems reasonable. But I'd recommend being very, very
>> careful with environment parsing between multiple old and new versions
>> of client, agent, and server..
>
> IMO having another environment variable with similar meaning is not a good
> design. In shell scripts it will be left alone, so having another ssh-agent
> active by error, and similar things.
>
>
> Well, I can offer a few ideas.
>
> One is to use the ":" separator, like in $PATH. Yes, it got discarded for
> various reasons in the other thread; yes, X11 uses that for display names,
> but observe:
>
>     $ echo $DISPLAY
>     :0
>     $ ls -la /tmp/.X11-unix/X0
>     srwxrwxrwx 1 root root 0 Sep 26 22:36 /tmp/.X11-unix/X0
>
> Although the display has a ":" in it, the socket in the filesystem doesn't;
> so I guess that scripts wanting to store a SSH agent per-display (instead
> of per-user) can get that working, too.

If you (or any openssh developer) buys the idea, the patch is done and
we can go for it :-)

>
> Whitespace (with a fixed set, eg. space and tab - not any 'whitespace'
> unicode points) would be another idea, but see IFS, quoting, etc.
>

Yeah, but if we are using a list with a separator I would prefer to go
with ":" (as the $PATH) ...

>
> The second idea is to have $SSH_AUTH_SOCK point to a *directory*, and to
> use the sockets in there in ASCII alphanumeric order - so the default agent
> would register itself with as "/tmp/ssh-<random>/500-agent.8903", and other
> agents could move themselved earlier or later in the list.
>

Hmm. Not sure if I like this one.
The reason is that when running the spice ssh-agent I would have to
place it in this specific folder and then be sure that it is the first
one (maybe it would involve renaming files, which would break
functionalities and so on ...)

> The third idea is similar: keep pointing to a file, but look at all
> glob("$SSH_AUTH_SOCK*") sockets in there, in ASCII alphanumeric order
> again.

I really did not understand this idea, sorry.

>
> Or, the other idea from the original question - have an agent push queries
> to the "previous" agent as a fallback.

I would have my agent pushing queries to the previous agent.
The main point is that the "dispatcher" agent must be in SSH_AUTH_SOCK
and we have to have a way to talk to know the path to the old agent
socket (and keep it unchanged).
So, from this came the idea to support a list on SSH_AUTH_SOCK whee I
would just prepend the "dispatcher" and that's it :-)

>
>
> I'd prefer the last one - because it transparently works with all programs
> that know how to access *one* agent socket (like some java implementations,
> etc.), followed by 3,2, and 1, I guess - although it doesn't matter as much
> with these any more.
>

The last one, you mean, having an agent pushing queries to the
previous agent? If yes, it would need one of the 3 ideas you suggested
to be implemented anyway, considering I understand your idea
correctly.

Best Regards,
--
Fabiano Fidêncio
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev




[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux