On 22 Sep 2015, Werner Koch said: > On Mon, 21 Sep 2015 18:49, [email protected] 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@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@mutilate 2 /home/nix% su - nix YubiKey for `nix': nix@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@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) _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
