Mailing List Archive

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

Hi, Damien.

Jun 22, 2022, 20:19 by dgouttegattat@incenp.org:

> Yes. `gnupg_SSH_AUTH_SOCK_by` is set by the agent at the same time as
> `SSH_AUTH_SOCK` (...)
> The `gpgconf` thing is to make sure `SSH_AUTH_SOCK` is always set to
> the correct path (...).

Thank you for the explanation...

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

...and for this important clarification.

> 2) You invoke gpg-agent in a profile script like this:
> eval $(gpg-agent --sh --enable-ssh-support daemon)
> 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.

Still, as indicated in the man page for gpg-agent under the
--enable-ssh-support option, ssh queries cannot themselves launch the
gpg-agent, so the agent needs to be started explicitly (creating the
socket) if one expects to initiate any SSH connections before said
agent can be autostarted by a gpg request.  For that, I just use
`gpgconf --launch gpg-agent` in my init script, and of course I will
be setting the SSH_AUTH_SOCK as required.

>Hope that helps,

You've been most helpful. Thank you once again.

Best regards,
Patrizio

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users