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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
