I am using an SSH key on a Yubikey, so I am using gpg-agent in place of ssh-agent. This is fundamentally working fine, except for the standard quirks (have to kill the scdaemon from time to time).

However, SSH key forwarding does not seem to work.

Here is my setup:

Office (RedHat 7.6) with Yubikey inserted, using openssh and gpg-agent -> destination: works.

Home (Windows 10) with Yubikey inserted, using Putty and gpg-agent -> Office: works

Home -> Office (gpg-agent) -> destination: error message "agent refused operation".

Home -> Office (ssh-agent) -> destination: works (I haven't actually tested this, but set it up many times before).

I have enabled agent forwarding on the Putty connection on Home, and also in /etc/ssh/sshd_config on Office.

Am I doing something wrong, or does gpg-agent not support agent forwarding when it is the intermediary?

  • Intermediary between what? I don't think that's how agent forwarding works...
    – user1686
    Dec 29 '18 at 23:48
  • I used the word intermediary to identify the ssh agent "in the middle" (Office, in my example) - the one that receives the key form the actual client ("Home"), and then sends it on to the final destination. Dec 30 '18 at 0:38

You're somewhat mistaken about how agent forwarding works:

  • Private keys are never sent anywhere. Agent forwarding uses the opposite mechanism: SSH clients running on the remote system will send signing requests back to your local system, where the local gpg-agent performs the operation and sends the result back.

    (Besides, it's impossible to extract a private key from your smartcard, so not even your local gpg-agent has the real private key.)

  • There is no such thing as an "intermediary agent". The only intermediate software are the local SSH client and the remote sshd daemon. The remote system does not start any ssh-agents or gpg-agents to handle forwarding, and if any were already running, those remain completely unused and unaware of this connection.

When you're at home and connect (for example) from HOME to OFFICE with agent forwarding enabled, you should see $SSH_AUTH_SOCK pointing to a socket owned by the sshd process which accepted your login – not to any standalone agent process. (You can check with sudo lsof $SSH_AUTH_SOCK.)

If your check shows that the remote system has actually pointed $SSH_AUTH_SOCK to its own ssh-agent or gpg-agent process, that is a problem: either the server hasn't accepted the agent-forwarding request, or your login scripts (~/.profile, etc.) are unnecessarily overwriting the environment variable.

When you then try to connect from OFFICE to yet another server, the ssh client on OFFICE sends a sign request through that socket directly to your local agent, mostly indistinguishable from a local request. (The local agent only sees the local ssh client as making this request, so there is no option for it to "not support" agent forwarding.)

If the local agent refuses this request, the troubleshooting process is mostly the same as with normal direct connections: if it's gpg-agent, make sure you have $GPG_TTY set; run gpg-connect-agent updatestartuptty /bye if necessary before making the initial connection and be careful to not use any gpg commands from other terminals.

  • You just solved my problem, thank you! You are correct; I did manipulate the SSH_AUTH_SOCKET variable on OFFICE. When connecting locally, that is a necessity to get gpg-agent to work. The solution was to update the profile script where it happens, and not load gpg-agent when SSH_CLIENT is set. Thank you again! And sorry about the sloppy phrasing re. private key forwarding. Of course, the private key remains on the local machine only. Dec 31 '18 at 4:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.