I'm sure this is general knowledge but anyway: never enable SSH agent forwarding by default if you log into any systems that you don't trust 100%. It gives whoever has root on that system the ability to log into anything else your SSH agent can connect to. Either explicitly pass -A or add host entries to ~/.ssh/ssh_config to enable it for the scenarios you need it.
For context: when you log into a remote site using an SSH key, the remote site sends a challenge and you sign that challenge with your private key and send the signature back. The remote site verifies that and if it matches the public key that's in authorized_keys, it lets you log in.
If you forward your agent to a remote system, ssh on the remote system can ask your local agent to sign a challenge so you can log into a further remote system. But that also means anyone on the remote system who can impersonate you can also ask your local agent to sign whatever challenges they want, which means they can then log into any systems you have key-based authentication to
So you forward your agent to A so you can log into B. Someone who has root on A can now ask your agent to sign a challenge for any system that you can log into using keys that are in your agent
So eg for the love of god do not enable agent forwarding for github.com because anyone who compromises github.com can then log into any site your keys have access to
@mjg59 what legitimate use case is there at all for agent forwarding that ProxyJump doesn't cover? I can't remember to ever have used agent forwarding.
@jomo In my case, providing a tunneling mechanism back to the local system so I can use local WebAuthn tokens to satisfy queries triggered on the remote machine
@mjg59 could you elaborate? I don't see how the middle man is required for that, as ProxyJump allows you to use your local ssh agent, but the connection over the jump host is encrypted. Am I missing something?
Add comment