我在 Yubikey 上使用 SSH 密钥，因此我使用 gpg-agent 代替 ssh-agent。这基本上运行良好，除了标准怪癖（必须不时终止 scdaemon）。
但是，SSH 密钥转发似乎不起作用。
这是我的设置：
插入 Yubikey 的 Office（RedHat 7.6），使用 openssh 和 gpg-agent -> 目标：有效。
家庭版（Windows 10）插入 Yubikey，使用 Putty 和 gpg-agent -> Office：有效
主页 -> 办公室（gpg-agent） -> 目的地：错误消息“代理拒绝操作”。
主页 -> 办公室（ssh-agent） -> 目的地：有效（我实际上没有测试过这一点，但之前已经设置过多次）。
我已经在 Home 上的 Putty 连接上启用了代理转发，并且在 Office 上的 /etc/ssh/sshd_config 中启用了代理转发。
是我做错了什么，还是 gpg-agent 作为中介时不支持代理转发？
答案1
您对代理转发的工作方式有些误解：
私钥永远不会被发送到任何地方。代理转发使用相反的机制：在远程系统上运行的 SSH 客户端将发送签署请求返回到本地系统，本地 gpg-agent 执行操作并将结果发回。
（此外，不可能从您的智能卡中提取私钥，因此即使您本地的 gpg 代理也没有真正的私钥。）
根本不存在“中介代理”这种东西。唯一的中间软件是本地 SSH 客户端和远程 sshd 守护程序。远程系统不会启动任何 ssh 代理或 gpg 代理来处理转发，即使任何代理或代理已在运行，它们也完全未使用，并且不知道此连接。
当你在家并启用代理转发功能从家里连接到办公室时，你应该看到 $SSH_AUTH_SOCK 指向由sshd接受您登录的进程 – 而不是任何独立代理进程。（您可以使用 进行检查sudo lsof $SSH_AUTH_SOCK。）
如果您的检查显示远程系统实际上已将 $SSH_AUTH_SOCK 指向其自己的 ssh-agent 或 gpg-agent 进程，则说明存在问题：服务器尚未接受代理转发请求，或者您的登录脚本（~/.profile 等）不必要地覆盖了环境变量。
当您尝试从 OFFICE 连接到另一台服务器时，远程控制OFFICE 上的客户端通过该套接字直接向您的本地代理发送签名请求，主要是与本地请求没有区别。（本地代理只能看到本地远程控制客户端发出此请求，因此没有“不支持”代理转发的选项。）
如果本地代理拒绝此请求，故障排除过程与正常直接连接大致相同：如果gpg-代理，请确保您已设置 $GPG_TTY；gpg-connect-agent updatestartuptty /bye在进行初始连接之前，如有必要，请运行并注意不是从其他终端使用任何 gpg 命令。