SSH_AUTH_SOCK - to set or not to set?

Damien Goutte-Gattat dgouttegattat at incenp.org
Wed Jun 22 22:19:46 CEST 2022


On Wednesday, 22 June 2022 17:34:45 BST theaetetos--- via Gnupg-users wrote:
> unset SSH_AGENT_PID
> if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
> export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
> fi
> 
> I don't understand the condition being checked, but I gather the whole
> thing is simply a more robust version of my ~/.profile two-liner.

Yes. `gnupg_SSH_AUTH_SOCK_by` is set by the agent at the same time as 
`SSH_AUTH_SOCK`. By checking that variable instead of `SSH_AUTH_SOCK` 
directly, you avoid the case where `SSH_AUTH_SOCK` has already (incorrectly) 
been set by something else (for example by an earlier profile script).

The `gpgconf` thing is to make sure `SSH_AUTH_SOCK` is always set to the 
correct path, because you should not assume the socket will always be in 
GnuPG’s home directory. With modern GnuPG versions it is normally somewhere 
under [/var]/run.


> Meanwhile, the first sentence of the gpg-agent(1) man page for the
> --enable-ssh-support option,which I set in my gpg-agent.conf, tells
> us: The OpenSSH Agent protocol is always enabled, but gpg-agent will
> only set the SSH_AUTH_SOCK variable if this flag is given.
> 
> So should 'SSH_AUTH_SOCK' be set by the user or can gpg-agent indeed
> take care of that?

In most cases you should set `SSH_AUTH_SOCK` yourself in your profile script.

There are two cases where the sentence you are referring to in gpg-agent(1) is 
relevant:

1) You use gpg-agent to spawn a new program (e.g. a shell):

  $ gpg-agent --enable-ssh-support --daemon /bin/sh

In that case, the agent will take care of exporting `SSH_AUTH_SOCK` before 
spawning the shell, so it does not need to be done in the shell’s profile 
script.


2) You invoke gpg-agent in a profile script like this:

  eval $(gpg-agent --sh --enable-ssh-support daemon)

In this case, the agent will print to stdout the appropriate `export 
SSH_AUTH_SOCK` stanza, which will then be evaluated by the `eval` command, 
resulting in the variable being exported in the shell’s environment.

This used to be a pretty standard way of both starting the agent *and* making 
sure the environment variables SSH_AUTH_SOCK and GPG_AGENT_INFO were set, back 
in the times before the start-on-demand mechanism was devised.

Nowadays, with the start-on-demand mechanism (which made GPG_AGENT_INFO 
obsolete), I don’t think there’s any compelling reason to still use that 
method, but it’s still there.

Hope that helps,

- Damien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220622/b043c5e2/attachment.sig>


More information about the Gnupg-users mailing list