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 2015-05-30 at 15:00 +0200, Kasper Dupont wrote:> 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.As validation for what Kasper is saying, so that others know that it's not just him: $work would use the feature you describe. At present, the key1 that you describe is unencrypted :( but is used for perimeter access, while key2 is used for intra-cluster access, but because it's forwarded onto less trusted hosts, can't be allowed to be used for getting into the cluster in the first place -- we constrain the impact of a breach. Not ideal. We'd like to move to using transient certificates issued for perimeter access, using OpenSSH CA, but that requires that the key1 role be loaded from an agent. If we move to the same transient certificate used for the key2 role then we get all the benefits of short-lived proof, but we lose our containment of impact of breach. So if you come up with a solution letting the ssh(1) command be told to use one agent for auth to the remote host but to pass a different agent as the forwarded auth signer, we would use it too. -Phil
On Sat, May 30, 2015 at 10:38 AM, Phil Pennock <phil.pennock at globnix.org> wrote:> On 2015-05-30 at 15:00 +0200, Kasper Dupont wrote: >> 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. > > As validation for what Kasper is saying, so that others know that it's > not just him: > > $work would use the feature you describe. At present, the key1 that you > describe is unencrypted :( but is used for perimeter access, while key2 > is used for intra-cluster access, but because it's forwarded onto less > trusted hosts, can't be allowed to be used for getting into the cluster > in the first place -- we constrain the impact of a breach. Not ideal. > > We'd like to move to using transient certificates issued for perimeter > access, using OpenSSH CA, but that requires that the key1 role be loaded > from an agent. If we move to the same transient certificate used for > the key2 role then we get all the benefits of short-lived proof, but we > lose our containment of impact of breach. > > So if you come up with a solution letting the ssh(1) command be told to > use one agent for auth to the remote host but to pass a different agent > as the forwarded auth signer, we would use it too.The workable, but fugly solution is to load an ssh-agent with the keys you want in environment two, keep a local unencrypted private key for permiter access to environment one stored in a shielded, protected, ideally locally disk partition encrypted location, and set up $HOME/.ssh/config with a "Host" entry to specify that non-standard-location unencrypted key location to use for accessing that permiter host or those perimeter hosts. I don't like this solution myself, but it satisfies all the stated requirements of "I don't want to keep typing my perimeter key passphrase" I'll also point out that with Gnome and KDE there are wallets to hold keys and to unlock them once in the wallet that might be useful. Another workaround is to set an ssh-agent with both keys and automatically delete that first key, if present, in your .bashrc or .login procedures in the remote account. That doesn't keep the first private key around for repeated logins, but that might be enough for some circumstances. Mind you, I've never been complete thrilled with ssh-agent. If you really want to segregate credentials for different environments, you might look into Kerberos based authentication, which can provide a very different approach to finer grained credential management. I just wish I could get it to work with Subversion.....
On 30/05/15 15:00, Kasper Dupont wrote:> 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.Have you considered launching a master process to server1 at the beginning of the session? That way, you will only need to provide the password for key1 once.