> Not every org's policy allows adding unaudited ad-hoc SSH keys.
Then audit them and get them in the process. Agent forwarding is too big of a risk.
> Definitely not always, if the hosts you store these keys on are not as hardened as you local machine (or a hardware key connected to it).
Once you use agent forwarding, the keys are no longer protected on your local machine. (Ironically, this RCE is precisely because of the requirement to whitelist hardware keys!)
I need to read the source, I’m confused how -J actually works. Is the bastion doing auth and the downstream machines trusting? Or does it auth first and then forwarding a :22 connection from downstream back to localhost? Or something else entirely?
Just my understanding of the manpage and TCP forwarding (-L): an SSH connection will be established to the jump host, which then establishes a connection on port 22 to the destination. The local machine now has a forwarded connection to the destination and uses that to establish a second SSH connection between them.
Between local and jump host, there will be two layers of encryption. The jump host decrypts the outer layer, and the two ends the inner layer.
c) use proxyjump (-J) to access bar (https://www.man7.org/linux/man-pages/man1/ssh.1.html), and/or
d) generate a new private key on foo and use that to access github.
You might think that's a crazy waste of time compared to forwarding, but it's actually much, much safer and actually only takes a moment:
and then just paste that in Github.See also https://userify.com/docs/jumpbox for more jumpbox docs.