4 ms·

Better options: c) use proxyjump (-J) to access bar (https://www.man7.org/linux/man-pages/man1/ssh.1.html https://www.man7.org/linux/man-pages/man1/ssh.1.html)

Better options: c) use proxyjump (-J) to access bar (https://www.man7.org/linux/man-pages/man1/ssh.1.html 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: ssh-keygen -t ed25519 cat ~/.ssh/id_ed25519.pub and then just paste that in Github. See also https://userify.com/docs/jumpbox https://userify.com/docs/jumpbox for more jumpbox docs.

lxgr 3y ago
> d) generate a new private key on foo and use that to access github. > [...] only takes a moment [...] Not every org's policy allows adding unaudited ad-hoc SSH keys. > [...] much, much safer [...] 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).
- gunapologist99 3y ago
  > 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!)
berkle4455 3y ago
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?
- momentoftop 3y ago
  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.

lxgr 3y ago

> d) generate a new private key on foo and use that to access github. > [...] only takes a moment [...] Not every org's policy allows adding unaudited ad-hoc SSH keys. > [...] much, much safer [...] 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).

gunapologist99 3y ago
> 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!)

berkle4455 3y ago

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?

momentoftop 3y ago
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.