Remote forwarding gnupg extra-socket?

[Werner Koch]

On Mon,  9 Mar 2020 13:02, Andrew Gallagher said:

> In fact, you can still configure all of the above, but doing so is now
> next to useless. Since v2.1 there is no way to tell the remote gpg
> instance to use a non-default socket, and there is no reliable way to

Actually --extra-socket was introduced with 2.1.1 and the /var/run
standard location was introduced with 2.1.13.  So I don't understand why
you think anything has changed for --extra-socket except that it is now
always generated unless you configure "extra-socket /dev/null"


> tell ssh to mount the forwarded socket on the default location -- the
> default is now under XDG_RUNTIME_DIR which is unpredictable in
> principle, and ssh does not allow the use of remote envars in

XDG_RUNTIME_DIR is not used:

  /* It has been suggested to first check XDG_RUNTIME_DIR envvar.
   * However, the specs state that the lifetime of the directory MUST
   * be bound to the user being logged in.  Now GnuPG may also be run
   * as a background process with no (desktop) user logged in.  Thus
   * we better don't do that.  */

We use /run/user/<uid> instead.

[Site note: It seems that this directory is sometimes used for
 XDG_RUNTIME_DIR or at least handled in that way.  Which is a pretty
 annoying misfeature.  I often fall into this trap:

  foo-box$ ssh -X bar-box
  bar-box$ ssh foo-box
  foo-box$ exit
  bar-box$

 After the "exit" elogind removes /run/user/<uid> and futher work (in
 paricular new ssh connections) stop working because SSH_AUTH_SOCK
 points to a now non-existing socket.
 Mitigation is "loginctl enable-linger".
]


> Not only that, but if you are already logged in to the remote machine by
> other means you MUST NOT use the default socket location lest you break
> the existing session.

You mean you are running a gpg-agent on the remote box as well?  Right
in this case you should use a different home directory for the remote use
of gpg-agent.  gpgconf has options to help you with that.  And of course
you should use

   --no-autostart

     Do not start the gpg-agent or the dirmngr if it has not yet been
     started and its service is required.  This option is mostly useful
     on machines where the connection to gpg-agent has been redirected
     to another machines.  If dirmngr is required on the remote machine,
     it may be started manually using gpgconf --launch dirmngr.

with your remote gpg.

> Can we please PLEASE have GPG_AGENT_SOCK back in the short term?

No, the removal solved so many problems that it will definitely not be
added again.  The rule is: one gnupg homedir - one socket directory.

> In the long term, it might be more productive to overload ssh-agent. IFF
> the forwarded ssh-agent is really a gnupg-agent with enable-ssh-support,

That is a misunderstanding: gpg-agent does not emulate ssh-agent but
implements the ssh-agent-protocol; in that protocol gpg-agent is the
server and ssh is the client.

> The ssh-agent protocol allows for vendor-specific protocol extensions,
> which would appear to be perfectly suited for this:

Yes, it would be nice if the client site (ssh)  would send certain
environment variables via the ssh-agent-protocol, so that gpg-agent
knows hows where to pop up the pinentry (that is what the gpg does).
It would also be very nice if ssh could be extended to call a configured
tool if it does not find an agent and then try again.  This way we would
get auto start also via ssh.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2734 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200327/d7cb1c52/attachment.sig>