gpg agent forwarding (via ssh) totally broken with 2.1 and NFS-mounted $HOME

[Nix]

On 22 Sep 2015, Werner Koch said:

> On Mon, 21 Sep 2015 18:49, nix at esperi.org.uk said:
>
>> (It's not that the fs doesn't allow for special files -- it's that it's
>> distributed, but the semantics of AF_UNIX socket creation assume that it
>> isn't.)
>
> Depends on the file system.  At least some NFS versions don't allow
> special files at all.
>
>> Useful! ... though this seems more likely to be *used* if it applied to
>> all assuan sockets at once, rather than one at a time.
>
> That would require a lot of changes.  The redirect file approach is
> mostly a wrapper and works transparently on the client site.
>
>> It seems to work much better now, though of course only assuan can
>> follow these links, so your SSH_AUTH_SOCK has to point at wherever you
>> pointed them, as does your ssh agent forwarding.
>
> Right, but you have to set SSH_AUTH_SOCK yourself anyway.

Indeed. Of course, what to set it *to* is another problem. As I learned
just now, the whole "pinentry run from gpg agent in its ssh-agent
disguise" thing implodes in chaos if the user under whom you are running
ssh-add is not the same as the one gpg-agent is running as: perhaps it's
on a different machine (access X through an SSH tunnel) or at the very
least on a different TTY. If it were the same user, you could run
"gpg-connect-agent updatestartuptty /bye" (which I am now running at
every interactive shell invocation in a desperate attempt to make things
work) -- but you can't because that is not allowed over a
restricted/remote connection and because gpg-agent almost certainly
can't access the other user's TTY or proxied DISPLAY anyway -- it wants
the *original* DISPLAY, or more likely it wants a GPG-written
replacement for ssh-add which uses libassuan and thus can ask for the
passphrase as the right user on the right machine.


btw, because I can't figure out how to add comments to bugs I didn't
open: I can confirm issue 2053. Without --disable-ccid, or with an
exclusive open of pcscd (from pcsc-lite 1.8.14 with the autospawn code
hacked back in because not everyone in the whole world can rely on
systemd to do that for them), scdaemon gets itself into a terrible
tangle after very simple operations with a dual-form device such as the
Yubikey. e.g. this is a 100% reproducer for me:

nix at mutilate 1 /home/nix% ssh-add -l
2048 SHA256:QQPl0xOGzqRa6PIUvshzRYaUoSJxjyxU9MreFRCw+DY cardno:000603639540 (RSA)

# at this point, the agent is working. Let's do something that uses the
# Yubikey in OTP mode, like a su to myself and then an exit.

nix at mutilate 2 /home/nix% su - nix
YubiKey for `nix': 

nix at mutilate 3 /home/nix% gpg --card-status
gpg: selecting openpgp failed: Conflicting use
gpg: OpenPGP card not available: Conflicting use

# Oh dear. Worse yet, ssh-add doesn't know about this problem so it's as
# if the smartcard keys have just silently vanished:

nix at mutilate 5 /home/nix% ssh-add -l
The agent has no identities.

Following this, the agent is fubared. gpg-agent is so stuck it has to be
kill -9ed and isn't even waiting for dead children anymore, though the
backtrace is not much help (I got backtraces of all three and they're
all chatting to each other via libassuan, that's all: it's probably a
deadlock somewhere since they all appear to be waiting for responses
from each other).

I've seen this after a few dozen attempts when doing nothing but
smartcard ssh-agent operations -- a dual-form device is not *necessary*,
it's just that using one seems to be a way to trigger the problem
reliably. (Also it's the only smartcard I've got.)

With a non-exclusive open, this problem does not go away, but it becomes
radically less frequent.

-- 
NULL && (void)