Ángel González
2015-Feb-01 23:48 UTC
Filtering which identities are forwarded by ssh-agent to a given host
On 02/02/15 00:18, Damien Miller wrote:> On Sun, 1 Feb 2015, Bill Nugent wrote: >> Host network-a-gateway.example.com >> ForwardIdentity .ssh/network-a-2014-10-12 >> and allow additional ForwardIndenty to allow additional keys. > It's not possible to do this unfortunately, but is a feature that I've > wanted for a long time. Implementing it required teaching ssh enough > of the agent protocol to filter requests sent through it, and doing > it exactly right so that users' agents aren't exposed when they connect > to a malicious server - so it's not without risk.IMHO the way to go is not teach ssh the agent protocol, but modify the agent protocol so that each request gets prepended the hostname requesting it (forwarded connections would contain the full chain) Then the agent itself would decide which keys to expose to such host. "foo is available for any host", "Provide network-a-key only to ssh.network-a.com and anything that passed through ssh.network-a.com." "Key bar is shown to all hosts but a confirmation dialog will be shown to the user pointing at the host requesting it.", and so on. Regards
Damien Miller
2015-Feb-02 02:53 UTC
Filtering which identities are forwarded by ssh-agent to a given host
On Mon, 2 Feb 2015, ?ngel Gonz?lez wrote:> IMHO the way to go is not teach ssh the agent protocol, but modify the agent > protocol so that each request gets prepended the hostname requesting it > (forwarded connections would contain the full chain)Then you have to modify all of ssh, sshd and ssh-agent and doesn't work until they are all upgraded. Moreover, unless you include signing (by the hostkey) for forwarded hops and verification of same at the agent side, then you can't trust anything past the first hop. That doesn't seem any easier to deploy or to get right (the hostkey signing would be particularly scary). -d
Ángel González
2015-Feb-03 22:27 UTC
Filtering which identities are forwarded by ssh-agent to a given host
On 02/02/15 03:53, Damien Miller wrote:> On Mon, 2 Feb 2015, ?ngel Gonz?lez wrote: > >> IMHO the way to go is not teach ssh the agent protocol, but modify the agent >> protocol so that each request gets prepended the hostname requesting it >> (forwarded connections would contain the full chain) > Then you have to modify all of ssh, sshd and ssh-agent and doesn't > work until they are all upgraded.Only ssh-agent and ssh (and the change to the former could be trivial)> Moreover, unless you include signing (by the hostkey) for forwarded hops > and verification of same at the agent side, then you can't trust anything > past the first hop.I wasn't attempting to go that far. Just accountability, similar to how Received: headers work in SMTP. And yes, you can't trust anything past the first evil hop. Still, I see many benefits compared to the current all-or-nothing agent trust. (Of course, to be really sure that nobody intercepts the agent request, you MUST perform the ssh connection locally, with a ProxyCommand. Full Stop)
Michael Ströder
2015-Feb-07 20:06 UTC
Filtering which identities are forwarded by ssh-agent to a given host
Damien Miller wrote:> On Mon, 2 Feb 2015, ?ngel Gonz?lez wrote: > >> IMHO the way to go is not teach ssh the agent protocol, but modify the agent >> protocol so that each request gets prepended the hostname requesting it >> (forwarded connections would contain the full chain) > > Then you have to modify all of ssh, sshd and ssh-agent and doesn't > work until they are all upgraded.Disclaimer: I don't consider myself to be an expert in this field. I'm using ssh-add -c to be asked each time the key is requested. At least it would be helpful if the hostname is displayed for which the key is requested. Because sometimes things happen concurrently and one cannot decide anymore for which action the dialogue pops up. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4252 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150207/d50d4014/attachment-0001.bin>