4 ms·

The remote ssh process asks your host to unencrypt it's traffic? Your process takes an encrypted stream, sends the plaintext, and your keys never leave your mac

The remote ssh process asks your host to unencrypt it's traffic? Your process takes an encrypted stream, sends the plaintext, and your keys never leave your machine. That's...incredibly clever, although I can only think of one scenario where it would be necessary (navigating securely through a sequence of ssh sessions where some of the secondary hosts are inaccessible from your originating host. E.g. a kind of "secure trojan horse". Sometimes I feel just so awed at the ingenuity of people, especially with software and computers.

throwaway2048 11y ago
its very useful for so called "Bastion Hosts", an SSH server that allows further access into the network and is totally locked down.
- laumars 11y ago
  This is what I do for my home network. I hadn't realised it had a name (though not at all surprised)
- creshal 11y ago
  You don't need agent forwarding for that. Just use ssh's dumb tcp forwarding and keep your agent on your local host. Ex.: Host bastion.company ProxyCommand none Host *.company ProxyCommand ssh -W %h:%p bastion.company
  - mentat 11y ago
    Because enabling tcp forwarding is so much more safe on a jump box? That's just asking for another pile of unauditable trouble.
    - creshal 11y ago
      Safer than dumping all your private keys onto the jump box and using that to validate the final target? Why yes. This way, your local ssh client validates the final target public key, not the jump box.
      - mentat 11y ago
        The whole point of agent forwarding is that you don't have to place your keys on the jump box. With -c for per use confirmation it seems much more secure.
        creshal 11y ago
        > The whole point of agent forwarding is that you don't have to place your keys on the jump box. A socket that allows dumping the keys isn't really an improvement. If the box is compromised, agent forwarding can still be abused. > seems much more secure. Emphasis on "seems".
- beagle3 11y ago
  I know it as a "jump host" or "jump box". Regardless, it's still not a good idea to have agent forwarding - what about the boxes you forward to? Do you trust them not to abuse the forwarding trust (Is there a way to limit forwarding trust to just one machine?) Also, I used to add every jump combination into my .ssh/config file, but came across a wonderful trick that makes it unnecessary: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts#Recursively_chaining_gateways https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_J...
hamburglar 11y ago
Not exactly. The remote host, which you have forwarded your agent to, tries to log onto your production host using your public key, and when the production host sends it a signing challenge to prove it has the authority of your private key, it can simply ask your ssh agent to do that signing. Once that is complete, you are logged in and the session has a session key that has nothing to do with your pub/private keys. The ssh agent does not do decryption, it just gets the session started.
micaeked 11y ago
Another example is if I want to transfer something from server A to server B, without it going through my shitty little pipe, and without storing the private key on either server.

throwaway2048 11y ago

its very useful for so called "Bastion Hosts", an SSH server that allows further access into the network and is totally locked down.

laumars 11y ago
This is what I do for my home network. I hadn't realised it had a name (though not at all surprised)
creshal 11y ago
You don't need agent forwarding for that. Just use ssh's dumb tcp forwarding and keep your agent on your local host. Ex.: Host bastion.company ProxyCommand none Host *.company ProxyCommand ssh -W %h:%p bastion.company
- mentat 11y ago
  Because enabling tcp forwarding is so much more safe on a jump box? That's just asking for another pile of unauditable trouble.
  - creshal 11y ago
    Safer than dumping all your private keys onto the jump box and using that to validate the final target? Why yes. This way, your local ssh client validates the final target public key, not the jump box.
    - mentat 11y ago
      The whole point of agent forwarding is that you don't have to place your keys on the jump box. With -c for per use confirmation it seems much more secure.
      - creshal 11y ago
        > The whole point of agent forwarding is that you don't have to place your keys on the jump box. A socket that allows dumping the keys isn't really an improvement. If the box is compromised, agent forwarding can still be abused. > seems much more secure. Emphasis on "seems".
beagle3 11y ago
I know it as a "jump host" or "jump box". Regardless, it's still not a good idea to have agent forwarding - what about the boxes you forward to? Do you trust them not to abuse the forwarding trust (Is there a way to limit forwarding trust to just one machine?) Also, I used to add every jump combination into my .ssh/config file, but came across a wonderful trick that makes it unnecessary: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts#Recursively_chaining_gateways https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_J...

hamburglar 11y ago

Not exactly. The remote host, which you have forwarded your agent to, tries to log onto your production host using your public key, and when the production host sends it a signing challenge to prove it has the authority of your private key, it can simply ask your ssh agent to do that signing. Once that is complete, you are logged in and the session has a session key that has nothing to do with your pub/private keys. The ssh agent does not do decryption, it just gets the session started.

micaeked 11y ago

Another example is if I want to transfer something from server A to server B, without it going through my shitty little pipe, and without storing the private key on either server.