Upgrading from gpg1 to gpg2: lots of trouble, need help

[gnupg at raf.org]

Daniel Kahn Gillmor wrote:

> On Thu 2017-12-21 16:19:00 +1100, raf wrote:
> > Sorry, I thought I already did. The 4th point above does not
> > work. When the public-facing host connects via ssh to the
> > key management host, and runs gpg, instead of it successully
> > connecting to the existing gpg-agent process that I started
> > minutes earlier, it starts a new gpg-agent process which
> > doesn't know the passphrase and so the decryption fails.
> >
> > Here are the gpg-agent processes after I start the first gpg-agent
> > process and preset the passphrase:
> >
> >   /usr/bin/gpg-agent --homedir /etc/thing/.gnupg --allow-preset-passphrase \
> >     --default-cache-ttl 3600 --max-cache-ttl 3600 --daemon -- /bin/bash --login
> >
> > Here are the gpg-agent processes after an inoming ssh connection that
> > attempts to use gpg:
> >
> >   /usr/bin/gpg-agent --homedir /etc/thing/.gnupg --allow-preset-passphrase \
> >     --default-cache-ttl 3600 --max-cache-ttl 3600 --daemon -- /bin/bash --login
> >   gpg-agent --homedir /etc/thing/.gnupg --use-standard-socket --daemon
> >
> > That second gpg-agent process should not exist. The gpg
> > process that caused it to be started should have connected
> > to the existing gpg-agent process. The sockets for it
> > existed but perhaps there was some reason why it didn't use
> > them.
> >
> > There must be some reason why gpg thinks it needs to start
> > gpg-agent. Perhaps it's because it's a different "user
> > session". They are from two different ssh connections after
> > all.
> 
> this is the part that i'm unable to reproduce.
> 
> Are both of these processes running as the same user account?

Yes. They are both owned by the user I am calling "thing".

> does something at some point destroy or mask the standard socket created
> by the first process, so that a new gpg invocation decides to start up a
> new instance of gpg-agent?

Nothing that I am aware of. The sockets are still there in the
file system. However, as soon as the incoming ssh connection
runs gpg which starts its own new gpg-agent, the original
screen+sudo+gpg-agent+bash "session" can no longer decrypt the
data. It's behaving "as if" the new gpg-agent has taken over the
sockets so connections via them no longer access the first
gpg-agent that knows the passphrase but rather access the second
gpg-agent that doesn't know the passphrase. I'm not saying that
that is what is happening, just that such behaviour might look
like what I'm seeing.

> if your old session was being terminated, then you'd expect the first
> agent to actually disappear.  that's not happening.
> 
> and neither of these agents is beign launched by systemd, because if it
> were it would have a --supervised .
> 
> > But when I su to the user in question, I get:
> >
> >   > systemctl --user is-enabled gpg-agent.service gpg-agent.socket gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket
> >   Failed to connect to bus: No such file or directory
> >
> > But it still reports as enabled with --global.
> > Maybe that's enough. I don't know.
> 
> are you su'ing with a login shell (i.e. with - or -l or --login), or
> not?

I would have used "-" but I was only using su for the purpose of
checking the systemctl's gpg-agent enabled status. I just tried
it again with "-" and got the same result as above.

For the actual decryption, I'm using sudo. From the original
post, the command to set things up contains something like:

  /usr/bin/screen -- \
  /usr/bin/sudo -u thing --set-home -- \
  /usr/bin/gpg-agent --homedir /etc/thing/.gnupg \
    --allow-preset-passphrase \
	--default-cache-ttl 3600 \
	--max-cache-ttl 3600 \
	--daemon $gpg_agent_info -- \
  /bin/bash --login

So the sudo doesn't have "-i" for a login shell (because
gpg-agent is run instead) but bash is run with "--login".

> > I am completely failing to understand what's going on here. :-)
> > Is systemd handling the sockets or not? There's no /run/user
> > directory for this user so probably not. Maybe I don't
> > understand --user and --global or systemd in general.
> 
> why is there no /run/user for this user?  if you're running a modern
> version of systemd, and your user has actually started a session, there
> should be a /run/user created automatically.

I don't know why. It's systemd 232-25+deb9u1.

>        --dkg

The main thing is that you can't reproduce the behaviour that
I'm seeing with the incoming ssh connection running gpg.

I take that as a good sign. It means that what I am trying to do
should work. When I get back to work, I'll do some tracing and
get a better look at what is happening when the incoming ssh
connection runs gpg and compare it to gpg when run from the
screen session before the incoming ssh connection takes place
(while it still works and can decrypt data).

Thanks,
raf