GNU bug report logs - #72248
home-gpg-agent `ssh-support?' breaks SSH agent forwarding

Previous Next

Package: guix;

Reported by: Ian Eure <ian <at> retrospec.tv>

Date: Tue, 23 Jul 2024 03:12:01 UTC

Severity: normal

To reply to this bug, email your comments to 72248 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#72248; Package guix. (Tue, 23 Jul 2024 03:12:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Eure <ian <at> retrospec.tv>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Tue, 23 Jul 2024 03:12:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ian Eure <ian <at> retrospec.tv>
To: bug-guix <at> gnu.org
Subject: home-gpg-agent `ssh-support?' breaks SSH agent forwarding
Date: Mon, 22 Jul 2024 19:13:44 -0700
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




This bug report was last modified 46 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.