What's a better solution if you want to be able to SSH across multiple machines? Do you need to always close the current connection to get back to localhost prior to a fresh SSH?
e.g. how would I ssh into foo, and then later into bar, or perhaps pull some code from github onto foo that is authenticated by my key?
> 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.
Just use a different, secure SSH Agent. I use gpg-agent and make it confirm every use of my private keys with me. Gpg-agent supports signing with a preloaded private key and nothing else, so it is immune to this attack and many others.
Please don’t call this the "correct" solution. It might work for you; it's not a general rule or widely accepted best practice.
Generating a key per host is just a different security model than key forwarding, and arguably a worse one if key forwarding is done defensively (i.e. forward a separate key, with only those permissions you would give to a key present on the connected host itself).
That is a TERRIBLE idea, if foo can be compromised. Even if you secure the private key with a passphrase, it still needs to be loaded into foo's memory, by a binary resident on foo, which can be used to exfiltrate that private key.
If you're confident foo cannot be compromised, then the whole point is moot anyway.
Make an ssh connection to foo with a port forward. Then make an ssh connection to bar through foo. Keys stay on your machine. I'm pretty sure there's built in features to do this.
it completely replaces the need for bastion hosts and ssh-agent at scale (I'm a hashicorp's paying customer)
compared to Teleport, boundary is lightweight (you dont need to install agent on each target server) and is integrated with the Vault for certificate based auth or simple cred brokering
I wrote a macOS app that supports using Vault Transit Engine keys with OpenSSH, as well as GnuPG and PKCS#11. (OpenSSH is supported via both the agent protocol and PKCS#11.) You can even use an Apple T2 (Secure Enclave) key for peer mTLS authentication to the Vault server. https://www.keymux.com/
Using this teams can share an SSH key without exposing the key; nor do you need to configure certificate PKI, use jump hosts, or otherwise change your existing software or workflows.
Teleport is far and away the leading solution in this area — certificate based end-to-end bastion style topology with many nice features including support for kubectl.
e.g. how would I ssh into foo, and then later into bar, or perhaps pull some code from github onto foo that is authenticated by my key?
It seems like the answer is either: a) ssh -A, or b) install my private key on foo.