Using two agents

[Thomas Calderon]

Hi,

You might want to have a look at Caml Crush [1] which could provide you
with a software alternative.
Caml Crush is a PKCS#11 filtering proxy which can be used with PKCS#11
devices (hardware or software).

One way to have the desired functionality would be to have two instances of
Caml Crush running on your machine.
The first one would allow the first key-pair to be used and the second
instance, the second key-pair.
Now when connecting to your first SSH server, you would use Caml Crush
client library to connect to the first instance.
You would also leverage SSH to redirect the UNIX socket of the second
instance while connecting.
Thus while connected to the first hop, you would be able to use Caml Crush
client library to access your second key-pair through the exposed socket
(linked to the second Caml Crush instance).

I am pretty sure it might do the trick, although I have not yet tried the
UNIX socket redirection feature.

Cheers,

Thomas Calderon

[1] https://github.com/ANSSI-FR/caml-crush

On Mon, Jun 1, 2015 at 3:28 AM, Damien Miller <djm at mindrot.org> wrote:

> On Sat, 30 May 2015, Kasper Dupont wrote:
>
> > As far as I can tell when the ssh command uses an agent to
> > authenticate to a server and then forwards an agent to that server, it
> > will always use the same agent for both purposes.
> >
> > Has there been any attempt to make it possible for the ssh command
> > to use two different agents, such that I can use one agent to
> > authenticate and then forward a different agent to the server?
>
> You could probably rig something up using the Unix domain socket
> forwaring that was added a couple of releases ago.
>
> More generally, I've long wanted the ability to restrict which keys are
> made available through a forwarded-agent but doing so either requires
> teaching ssh most of the agent protocol and moving ssh into the trust
> path for agent keys, or a more substantial rearchitecture of how agents
> are forwarded (giving each ssh a long-lived socket to the agent, or some
> sort of cookie that stood for one instead of creating socket on-demand).
>
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>