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.

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.

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.

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

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_J...

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

Because enabling tcp forwarding is so much more safe on a jump box? That's just asking for another pile of unauditable trouble.

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.

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.

> 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".

This is what I do for my home network. I hadn't realised it had a name (though not at all surprised)