4

I'm trying to follow these guides and answers

and anything else I can find to make this work:

  • SSH from macOS to ubuntu 18.04
  • Forward my local gpg agent so I can gpg --decrypt on the remote machine.

I already --exported and --imported my public key to the remote machine. The remote gpg reports the agent-socket to reside in /run/user/1001/gnupg/S.gpg-agent, and the extra socket in /run/user/1001/gnupg/S.gpg-agent.extra.

However, trying to ssh -v -R /run/user/1001/gnupg/S.gpg-agent:/Users/rasmus/.gnupg/S.gpg-agent.extra -l rasmus <remote-host> warns that

Warning: remote port forwarding failed for listen path /run/user/1001/gnupg/S.gpg-agent

Which is presumably because systemd already owns the remote socket.

$ sudo journalctl -xe
…
Mar 11 15:06:21 pact-cube sshd[4972]: error: bind: Address already in use
Mar 11 15:06:21 pact-cube sshd[4972]: error: unix_listener: cannot bind to path: /run/user/1001/gnupg/S.gpg-agent

What must I do to forward gpg agent from macOS to Ubuntu 18.04? The required GPG and SSH versions are used on both machines.

2
  • I would start by asking what are the port numbers being used and I would test using different ones that I am sure no other process is listening on. if this doesn't work please share more details about your networking and aso look all aspects regarding privileges and security -e.g. process owner has access to required files, forward ports, others are prevented from reading security files where you keep the secrets, etc. Jun 5, 2021 at 9:13
  • There are no TCP port numbers involved @JoseManuelGomezAlvarez, this question is about forwarding UNIX-domain sockets.
    – sampi
    Jul 23 at 20:51

2 Answers 2

1

Delete the stale socket file:

ssh mylinuxserver 'rm /run/user/1001/gnupg/S.gpg-agent'

and then connect:

ssh -vvv mylinuxserver

This assumes you have set up the RemoteForward in your ~/.ssh/config. It would look something like this:

# File: ~/.ssh/config
[...]
Host mylinuxserver
HostName mylinuxserver.example.com 
#RemoteForward <socket_on_remote_box>  <extra_socket_on_local_box>
RemoteForward /run/user/1001/gnupg/S.gpg-agent /Users/rasmus/.gnupg/S.gpg-agent.extra
[...]

In the verbose output, you should see something like:

debug1: remote forward success for: listen /run/user/1001/gnupg/S.gpg-agent:-2, \
   connect /Users/rasmus/.gnupg/S.gpg-agent.extra:-2

Using gpg-agent on the remote machine should then work.

To avoid needing to delete the stale socket file each time, add StreamLocalBindUnlink yes to the server's /etc/ssh/sshd_config, as suggested here: https://wiki.gnupg.org/AgentForwarding

A note to anyone trying to get this to work on Fedora Linux: I needed to enable two sockets on my Fedora Linux Workstation to get the socket activation to work:

systemctl --user enable gpg-agent.socket
systemctl --user enable gpg-agent-extra.socket

The gpg-agent.service then reported that it will be triggered on-demand by those two sockets:

$ systemctl --user status gpg-agent.service
○ gpg-agent.service - GnuPG cryptographic agent and passphrase cache
     Loaded: loaded (/usr/lib/systemd/user/gpg-agent.service; static)
     Active: inactive (dead)
TriggeredBy: ● gpg-agent-extra.socket
             ● gpg-agent.socket
       Docs: man:gpg-agent(1)
0

The easiest way to get gpg forwarding functional is to tell systemd to stop occupying those sockets.

systemctl --user disable gpg-agent.socket
systemctl --user disable gpg-agent-extra.socket
systemctl --user stop gpg-agent.socket
systemctl --user stop gpg-agent-extra.socket

With that done, the unnecessary problematic component is gone and it works flawlessly.

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.