Not U2F because it requires the systems to always have an internet connection. I could setup an authentication server on each machine to avoid that, but I think that would make replay attacks possible (nevermind, see EDIT). Also, since GPG is an option for this, it means that I can just depend on that for absolutely everything. If I break the key in two, I can use an encrypted backup of the GPG key to keep working (authenticating, decrypting, and signing) until I get a new yubikey and write the backup to it.
It's an -R forwarding what I want. -L would require the host I'm logging into to automatically login back to the host I'm at. That's something that raises way to many convoluted issues. By using -R and ControlMaster, and overriding ssh with one that sets up the forwarding first if the corresponding control socket does not exist, I can share the forwarding among all the ssh terminals I've opened to the same host.
I saw GPG_AGENT_INFO on the manpage, but it says that it's an obsolete environment variable that's now ignored. In my system, gpg2 is a symlink to gpg. I wondered if maybe gpg decided to ignore or use GPG_AGENT_INFO depending on $0, but from grepping the source I don't think it does. It only appears on documentation and automated tests. Still, it might be a good starting point to check the source of gpg 1.4 to get an idea of how to patch gpg2 to get the agent path from an environment variable. Thanks for the help.
EDIT: I made the U2F comment assuming that it works like OTP, but there is some material online referring to it as a protocol using a challenge-response mechanism. If that's the case, what I said would be false. Still, I feel I'm close to an ideal with GPG, so I'm not sure there would be something to gain by using U2F. Unfortunately, most of the material online about it is about using it to login to specific web services like Google.
EDIT 2: I was taking a quick look at pam-u2f[1], and I found this piece interesting:
> manual: Set to drop to a manual console where challenges are printed on screen and response read from standard input. Useful for debugging and SSH sessions without U2F-support from the SSH client/server. If enabled, interactive mode becomes redundant and has no effect.
I imagine this is in consideration with U2F keys that come with a keypad. Otherwise, terminal emulators would have to be extended to support an escape sequence with which it could recognize when a challenge has been presented to automatically pass it on to the key connected.
EDIT 3: Extending my terminal emulator like that and using pam-u2f (after extending it to use that escape sequence) would eventually lead to solving the problem of using sudo remotely. However, going the route of forwarding my gpg-agent also allows me to use gpg (and dependents like pass) remotely. It also seems relatively easier since the only step left for me to figure out is how to get gpg to accept the agent socket path via environment variable.
EDIT 4: On "U2F-support from the SSH client/server", I don't suppose adding an authentication method like that would work when chaining ssh interactively (calling ssh to another machine from a ssh session), like how you can forward ssh agents with -A. I wonder if it's possible to add U2F support to ssh agents. I imagine the agent works on a challenge-response mechanism too, in a sense. Maybe the agent can be made to work like a proxy to the key. That way, -A can be made to work to forward authentication to the key.
[1] https://developers.yubico.com/pam-u2f/