4 ms·
I know exactly how agent forwarding and ProxyJump work, but I'm having a hard time understanding what you mean. ProxyJump proxies your ssh connection, so conne
by metafunctor 8y ago
I know exactly how agent forwarding and ProxyJump work, but I'm having a hard time understanding what you mean.
ProxyJump proxies your ssh connection, so connecting from A to B via proxy X the connections go A->X and X->B.
You can use AgentForwarding with ProxyJump, in which case agent connections go B->X->A.
I cannot see how ProxyJump would somehow be an alternative to AgentForwarding. You can use both independently.
- Xylakant 8y ago> ProxyJump proxies your ssh connection, so connecting from A to B via proxy X the connections go A->X and X->B. No, it rather works like this: A -> B via X establishes A->X and then, through that connection tunnels a new ssh-connection from A->B. A->X, then X->B would require forwarding the Agent from A to X, so that the connection from X->B can authenticate using that agent. Proxying the connection does not require X to ever authenticate to B, the authentication happens straight from A->B (1). Thus, no agent (forwarding) needed. You can also chain ProxyJumps: A->X->Y->B tunnels A->B in A->Y which is then tunneled through A->X. In that regard, ProxyJump and ProxyCommand can replace AgentForwarding in most use cases. There are some uses where AgentForwarding is the only solution, though. (1) Added benefit: X never sees the actual traffic in unencrypted form and all port forwards A<->B work
- metafunctor 8y agoHehe, I think I figured out the source of the confusion. I was thinking that the threat is that a compromised B gives access to your keys via agent forwarding. Presumably if you make keys available on B, you need them there. There's nothing ProxyCommand does to help there. But you're talking about using ProxyCommand as an alternative for connecting A->X and then X->B, so keys are not available on X. That's of course an improvement.