Hi folks,
I've got two Fedora 36 machines I use in my office: a laptop that I log
into using the keyboard and monitor and a server that I ssh into from the
laptop. I have my GnuPG private keys on the laptop, and the public keys on
both the laptop and the server. Additionally, I've got my laptop
~/.ssh/config set up with a directive:
RemoteForward /run/user/1000/gnupg/S.gpg-agent /run/user/1000/gnupg/S.gpg-
agent
and when I ssh into the server using 'ssh -v' I see in the output the
following:
debug1: remote forward success for: listen /run/user/1000/gnupg/S.gpg-agent:-2,
connect /run/user/1000/gnupg/S.gpg-agent:-2
Now at this point I'm under the impression that if gpg were to be called on
the server, and it talks to the socket, it should be triggering my
gpg-agent on my laptop. This seems to work as long as the gpg-agent on the
server doesn't start up. If the gpg-agent on the server does start it
complains about no private keys (which makes sense, since the server
doesn't have the private keys).
I've read that systemctl is managing the sockets on Fedora 36, and that I
can prevent gpg-agent from starting on the server by 'mask'ing the handlers
for the sockets. So, on the server, there are /dev/null links in place:
lrwxrwxrwx. 1 root root 9 Jul 28 10:30
/etc/systemd/user/gpg-agent-browser.socket
-> /dev/null
lrwxrwxrwx. 1 root root 9 Jul 28 10:30 /etc/systemd/user/gpg-agent-extra.socket
-> /dev/null
lrwxrwxrwx. 1 root root 9 Jul 28 10:30 /etc/systemd/user/gpg-agent.service
-> /dev/null
lrwxrwxrwx. 1 root root 9 Jul 28 10:30 /etc/systemd/user/gpg-agent.socket
-> /dev/null
lrwxrwxrwx. 1 root root 9 Jul 28 10:30 /etc/systemd/user/gpg-agent-ssh.socket
-> /dev/null
lrwxrwxrwx. 1 root root 9 Aug 8 09:16
/etc/systemd/user/sockets.target.wants/gpg-agent.socket
-> /dev/null
Sometimes I am able to call gpg w/ any problem and other times gpg is
starting up gpg-agent and then failing because of the lack of private keys
on the server machine. Is there some other thing I should have been doing
to tell systemctl to stop trying to handle the sockets itself? Should I be
reconfiguring gpg to use different sockets than ones that systemctl is
trying to manage?
Jim
I've got two Fedora 36 machines I use in my office: a laptop that I log
into using the keyboard and monitor and a server that I ssh into from the
laptop. I have my GnuPG private keys on the laptop, and the public keys on
both the laptop and the server. Additionally, I've got my laptop
~/.ssh/config set up with a directive:
RemoteForward /run/user/1000/gnupg/S.gpg-agent /run/user/1000/gnupg/S.gpg-
agent
and when I ssh into the server using 'ssh -v' I see in the output the
following:
debug1: remote forward success for: listen /run/user/1000/gnupg/S.gpg-agent:-2,
connect /run/user/1000/gnupg/S.gpg-agent:-2
Now at this point I'm under the impression that if gpg were to be called on
the server, and it talks to the socket, it should be triggering my
gpg-agent on my laptop. This seems to work as long as the gpg-agent on the
server doesn't start up. If the gpg-agent on the server does start it
complains about no private keys (which makes sense, since the server
doesn't have the private keys).
I've read that systemctl is managing the sockets on Fedora 36, and that I
can prevent gpg-agent from starting on the server by 'mask'ing the handlers
for the sockets. So, on the server, there are /dev/null links in place:
lrwxrwxrwx. 1 root root 9 Jul 28 10:30
/etc/systemd/user/gpg-agent-browser.socket
-> /dev/null
lrwxrwxrwx. 1 root root 9 Jul 28 10:30 /etc/systemd/user/gpg-agent-extra.socket
-> /dev/null
lrwxrwxrwx. 1 root root 9 Jul 28 10:30 /etc/systemd/user/gpg-agent.service
-> /dev/null
lrwxrwxrwx. 1 root root 9 Jul 28 10:30 /etc/systemd/user/gpg-agent.socket
-> /dev/null
lrwxrwxrwx. 1 root root 9 Jul 28 10:30 /etc/systemd/user/gpg-agent-ssh.socket
-> /dev/null
lrwxrwxrwx. 1 root root 9 Aug 8 09:16
/etc/systemd/user/sockets.target.wants/gpg-agent.socket
-> /dev/null
Sometimes I am able to call gpg w/ any problem and other times gpg is
starting up gpg-agent and then failing because of the lack of private keys
on the server machine. Is there some other thing I should have been doing
to tell systemctl to stop trying to handle the sockets itself? Should I be
reconfiguring gpg to use different sockets than ones that systemctl is
trying to manage?
Jim