[akerl_]

The "authenticate" bit isn't really material here. GPG keys are, at their heart, just asymmetric private keys (most typically RSA these days, but there are plenty of other options). The authenticate/sign/certify bits are flags that client tools use to know which key to pick, they aren't enforced anywhere.

The reason your auth key is used for auth and signing key is used for signing is just because most GPG tools are helpful.

It's also worth noting that an ssh agent using agent forwarding exposes use of all the keys it knows about, not just the one used for the initial connection. So if you SSH to 1.2.3.4 with "-A", that host has the ability to poke your agent and ask for any keys it's got loaded up.

The "presumably they are smart" bit is also rather concerning. Being smart is generally not protection against mistakes. This isn't to say that gpg-agent allows malicious action, but we should start from a presumption that bugs exist, rather than just assume they don't.

[jlgaddis]

> So if you SSH to 1.2.3.4 with "-A", that host has the ability to poke your agent and ask for any keys it's got loaded up.

I'm sure you know this but just to be clear... if you're using "-A", that host has the ability to ask for operations to be performed using any keys it's got loaded up.

It can't just say, "Lemme have all those private keys you got!". That's the primary purpose of storing them in a separate device -- the actual keys themselves become inaccessible and aren't exposed. Again, the device keeps the keys internally and performs operations using them on your behalf.

Besides, in my case, even with an "offline master" key and three subkeys, the agent still only knows about the authentication key. The others don't get loaded into the SSH agent. I don't even use agent forwarding in the first place, but that's beside the point.