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?
--
Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6);
On Sat, May 30, 2015 at 8:00 AM, Kasper Dupont <kasperd at kdxdx.23.may.2015.kasperd.net> 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?That sounds really, really awkward, and would create a real "provenance" problem for the agent being accessed on the other side. What problem are you actually trying to solve?
On 30/05/15 08.34, Nico Kadel-Garcia wrote:> On Sat, May 30, 2015 at 8:00 AM, Kasper Dupont > <kasperd at kdxdx.23.may.2015.kasperd.net> 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? > > That sounds really, really awkward, and would create a real > "provenance" problem for the agent being accessed on the other side.This couldn't possibly be a problem for the other side, the other side will only ever know about one agent.> > What problem are you actually trying to solve?On my laptop I have key1 and key2. I can use key1 to log in on server1, and I can use key2 to log in on server2. I want neither key to leave the laptop, and only key2 is allowed to be forwarded to other hosts. I need to ssh to server1 and on server1 run an scp command to exchange files with server2. This approach works as long as key1 is not encrypted: ssh-agent bash ssh-add key2 ssh -i key1 -A server1 But if key1 is encrypted it is highly inconvenient to have to type my password each time I connect to server1. It is also prone to phishing attacks, because when I type the ssh command, how can I really know if the password prompt I see is from ssh needing to decrypt key1 or from server1 trying to get my decryption password. Starting two agents locally and loading key1 and key2 into separate agents is trivial. Storing the name of the socket for the first agent in a secondary environment variable before starting the second agent (and overwriting SSH_AUTH_SOCK) is also trivial. But now that I have two enviroment variables pointing to the two agents, I can't ask ssh to use the first agent to log me in on server1 and forward the other agent. Because ssh will use SSH_AUTH_SOCK for both purposes. It is surely possible to update the ssh command to support the use of two separate agents (for example by allowing the paths to the two sockets to be specified in two configuration options). I just want to know if anybody did this already, so I don't waste my time reinventing the wheel. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6);
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
On 01/06/15 11.28, Damien Miller 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.Wouldn't that require an updated server? What I had in mind would be a fairly simple client side change that wouldn't change the protocol used between client and server in any way.> > 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).I have seen such a thing implemented externally to the ssh client: http://serverfault.com/a/660299/214507 But if I were to use that tool, I would still like the ssh client to use the unfiltered agent to authenticate and then forward the filtered client. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6);
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 >