home-gpg-agent `ssh-support?' breaks SSH agent forwarding

  • Open
  • quality assurance status badge
Details
One participant
  • Ian Eure
Owner
unassigned
Submitted by
Ian Eure
Severity
normal

Debbugs page

Ian Eure wrote 8 months ago
(address . bug-guix@gnu.org)
87h6cgu7io.fsf@meson
I have a fairly standard agent setup for using a hardware token
for SSH and GPG.

On my local (Debian, currently) machine, gpg-agent’s configuration
has `enable-ssh-support', and my shell dotfiles set SSH_AUTH_SOCK
to the gpg-agent socket, which allows SSH to access the
authentication key on my token. Additionally, my SSH config has
`ForwardAgent yes', which allows the remote system to talk to the
local gpg-agent, enabling things like logging into a remote
machine and running `git pull' for repos accessed over SSH.

For this to work requires /conditionally/ setting SSH_AUTH_SOCK:
on the local host, it needs to be set to the local GPG agent; but
on a remote host, it needs to be the forwarded SSH agent. The
SSH_AUTH_SOCK variable is set by SSH when setting up the
connection, so all that’s needed is to check $SSH_CONNECTION, and
leave SSH_AUTH_SOCK untouched -- this is what my shell dotfiles
do.

Unfortunately, this breaks when logging into a remote system which
uses Guix Home’s `home-gpg-agent-service-type'. I initially
thought this was an issue converting my homegrown dotfile setup to
Guix Home, but after troubleshooting, this appears to be a Guix
Home bug. Specifically, the issue is the
`home-gpg-agent-environment-variables' procedure in (gnu home
services gnupg), which, if `ssh-support?' is enabled in
home-gpg-agent-configuration, *unconditionally* sets SSH_AUTH_SOCK
to the GPG agent socket. This works for the local host -- I can
log into remote systems from a Guix Home machine -- but breaks
when SSH’ing to a remote system using Guix Home.

I’m not sure how to fix this; home-gpg-agent-environment-variables
returns a list of variables to set, with no facility for
conditional logic. Use of bash config files would break for
anyone using a different shell -- and how would
`home-gpg-agent-service-type' know what shell the user has chosen?

If I unset `ssh-support?', it disables both the bad behavior, but
also the gpg-agent configuration which enables SSH agent support.

Right now, the only thing that seems like it might work is adding
another home-environment-variables-service-type which saves the
value of SSH_AUTH_SOCK to another variable, which my shell init
files can look at later in the process. This feels like a
graceless hack (and the base stuff to make this all work already
feels overly complex), and would require further hackery for the
same dotfiles to work on non-Guix Home systems, which at least
some of my configs still do.

The other option is to quit using `home-gpg-agent-service-type' at
all, and handle all this stuff manually. I don’t love it, but it
seems like probably the best option.

Thoughts?

Thanks,

— Ian
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 72248@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 72248
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help