[soheil]

Can't the server still pretend to be connecting to one of the specified hops? For example if -h 'allowed.com' is specified then in /etc/hosts/ wouldn't an entry to 127.0.0.1 allowed.com allow the local server to receive the key?

[akerl_]

There’s no such thing as “receiving the key”. At best, you can coerce the forwarded agent to sign things w/ a key that it has. It will never give you the key itself; that isn’t part of the agent’s available behaviors.

[tialaramex]

Yup. And because SSH is a well-designed protocol, the signature needed to prove your identity is fresh (both sides pick large random values) each time, so even though SSH agent was over-used and securing it better is important, even today you cannot obtain enduring credentials from it. If I cut off your access to my SSH agent today, you can't authenticate to my servers tomorrow using what you learned.

This also has the benefit that the SSH agent can offer this capability on behalf of physical hardware that won't give up the keys either. My Yubico Security Key won't tell anybody (even me) my SSH private keys, but since SSH agent only offers to make signatures, it can proxy that work to the Security Key as necessary.

The Yubico product won't sign anything without a physical gesture (touching a glowing icon on the key) and so now if my laptop is sat unused on my desk while I eat lunch it's impossible for a remote system to use my credentials to sign in to another system, even if it's hostile, and it has somehow taken over control of my local machine's SSH client or I've unwisely authorised SSH agent forwarding, because it cannot cause the touch sensor to get touched.

[misnome]

It looks like the dns name is just a convenience; it actually looks up the associated host key and uses that, not the hostname. So the attacker would have the private keys for the destination to make use of it; I think?