if I remember the config setting correct. Note however that this only limits the offered keys during the authentication phase. If you use AgentForwarding, this still has the entire keyring available afterwards.
CVE-2016-0777 doesn't interact with ProxyCommand in any special way. That said, after connecting to hostB with your example config above you will have 2 ssh sessions:
1) from your client to hostA
2) from your client to hostB
So to answer your question - no, vulnerable client on hostA is not a problem (or at least not in this particular use-case).
which is not very helpful if you for example want to run git via ssh or similar commands on the target server.
There's places where there are two alternatives: agent forwarding or copy the key. Using ssh agent forwarding allows me to use a smart card for the key. It still has it's problems but it's much better than having the key on the remote machine - for example the use of a smartcard mitigates this vulnerability since the key never enters the process memory.
Not sure which exact scenario do you have in mind with ssh+git. ProxyCommand method works just fine for me with my private jumphost in the middle and github on the far end.
Note that for ProxyCommand to work, you don't need a full shell on a jumphost, just "AllowTcpForwarding yes" is enough. On the other hand, with AgentForwarding method you do need a full shell on a jumphost.
If you have clean network path from your terminal to the dev vm, why need for either ProxyCommand or ForwardAgent - just ssh to the vm directly, no?
Of course local, not forwarded ssh-agent on the terminal would be super-handy to avoid typing pass-phrase time and again; but that's different and independent from ForwardAgent.
I do ssh directly to the VM. It sits behind a VPN connection at aws. I need to make ssh connections from there to github. The key resides on a smartcard in my laptops usb slot. And that's where ssh-agent/ForwardAgent comes into play. I forward my local key to the remote VM.
